sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bertrand Delacretaz (Jira)" <j...@apache.org>
Subject [jira] [Resolved] (SLING-9550) Support custom GraphQL Scalars
Date Fri, 03 Jul 2020 11:36:00 GMT

     [ 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)

Mime
View raw message