You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Bertrand Delacretaz (Jira)" <ji...@apache.org> on 2020/07/03 11:36:00 UTC

[jira] [Resolved] (SLING-9550) Support custom GraphQL Scalars

     [ https://issues.apache.org/jira/browse/SLING-9550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bertrand Delacretaz resolved SLING-9550.
----------------------------------------
    Resolution: Fixed

I have merged the feature/SLING-9550 branch into master, with basic support for scalars.

I'll resolve this ticket as the basic support for custom scalars is implemented, we can create more specific tickets for changes as needed.

> Support custom GraphQL Scalars
> ------------------------------
>
>                 Key: SLING-9550
>                 URL: https://issues.apache.org/jira/browse/SLING-9550
>             Project: Sling
>          Issue Type: Task
>          Components: GraphQL
>    Affects Versions: GraphQL Core 0.0.2
>            Reporter: Bertrand Delacretaz
>            Assignee: Bertrand Delacretaz
>            Priority: Major
>             Fix For: GraphQL Core 0.0.4
>
>
> We should support [custom scalars|https://www.graphql-java.com/documentation/v13/scalars/] in the GraphQL Core, which is a fancy way to say "custom data types". [https://github.com/graphql-java/graphql-java-extended-scalars] has examples of those.
> After a quick brainstorm with a colleague I think we need to following:
>  * A way to provide "named type converters" that define the Scalar names and how to parse and serialize them.
>  * A way to define "scalar namespaces" in the schemas, to avoid name collisions if multiple Scalars with the same name are used in different applications. That's probably a directive like the {{@fetcher}} that we already use, maybe something like {{@namespace(scalars='com.example.scalars')}}
> So far we've been able to avoid exposing the {{graphql-java}} APIs in the GraphQL Core APIs but I'm not sure if it makes sense here, will need to explore. If our APIs expose {{graphql-java}} APIs they should be under a {{sling.graphql.api.graphqljava}} package to make that clear.
> As an example use case we might add author name and email information to the sling-samples website example, using a custom scalar for the email.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)