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:22:00 UTC
[jira] [Commented] (SLING-9550) Support custom GraphQL Scalars
[ https://issues.apache.org/jira/browse/SLING-9550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150946#comment-17150946 ]
Bertrand Delacretaz commented on SLING-9550:
--------------------------------------------
As discussed at https://github.com/apache/sling-org-apache-sling-graphql-core/pull/1 we should support namespacing of the {{SlingScalarConverter}} services, we can use a schema directive:
{code}
directive @scalarNS(
name : String = "defaultScalars"
) on SCALAR
# Try first "defaultScalars/URL" and if not found "URL" converter
scalar URL
# Use the "specificScalars/Constant" converter
scalar Constant @scalarNS(name: "specificScalars")
{code}
The namespace is then used as a prefix for the "name" property of the {{SlingScalarConverter}} service, like {{specificScalars/Constant}}, similar to how the {{SlingDataFetcher}} services are defined,
I won't have time to implement this right now, just writing down the idea.
> 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)