[ 
https://issues.apache.org/jira/browse/SLING-9550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146159#comment-17146159
 ] 

Bertrand Delacretaz commented on SLING-9550:
--------------------------------------------

The current plan is to support something like this:

{code}
type Query {
    @scalars(namespaces:"com.example,org.apache.sling")
    phraseAnalyzer (phrase : InputPhrase) : PhraseAnalysisResult 
@fetcher(name:"scalars/phrase")
}
{code}

Where the {{InputPhrase}} and {{PhraseAnalysisResult}} Scalars need to be 
provided as OSGi services with an API that's TBD.

The {{@scalars}} directive might be useful to namespace the Scalar converters, 
to avoid collisions of common scalar names like "Email".

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

Reply via email to