sling-dev mailing list archives

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


Bertrand Delacretaz commented on SLING-9550:

As discussed at we should
support namespacing of the {{SlingScalarConverter}} services, we can use a schema directive:

directive @scalarNS(
    name : String = "defaultScalars"

# Try first "defaultScalars/URL" and if not found "URL" converter
scalar URL

# Use the "specificScalars/Constant" converter
scalar Constant @scalarNS(name: "specificScalars")

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:
>             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|]
in the GraphQL Core, which is a fancy way to say "custom data types". []
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

View raw message