[
https://issues.apache.org/jira/browse/SLING-10118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17331894#comment-17331894
]
Bertrand Delacretaz edited comment on SLING-10118 at 4/26/21, 9:08 AM:
-----------------------------------------------------------------------
Building a schema that's specific to the {{sling:resourceType}} of the current
Resource and taking request selectors into account is by design. It provides a
simple way to define multiple GraphQL endpoints with different schemas.
However I agree that in general you shouldn't need other attributes of the
resource such as its path or field values in order to generate a meaningful
schema.
h2. Potential breaking API change: getSchema
If users of this module agree to this breaking change (which we should ask on
our dev list) we might change the {{SchemaProvider}} API from
{code:java}
String getSchema(Resource r, String [] selectors)
{code}
to
{code:java}
String getSchema(String resourceType, String slingResourceSuperType, String []
selectors)
{code}
Which then allows us to cache the {{GraphQLSchema}} using the resourceType,
supertype and selectors as a cache key.
Would this change be ok for your use cases? If yes we can ask on the Sling dev
list before making this breaking API change. Considering the graphql-core
module is version {{0.0.9}} such breaking changes can be ok unless someone
objects.
was (Author: bdelacretaz):
Building a schema that's specific to the {{sling:resourceType}} of the current
Resource and taking request selectors into account is by design. It provides a
simple way to define multiple GraphQL endpoints with different schemas.
However I agree that in general you shouldn't need other attributes of the
resource such as its path or field values in order to generate a meaningful
schema.
If users of this module agree to this breaking change (which we should ask on
our dev list) we might change the {{SchemaProvider}} API from
{code:java}
String getSchema(Resource r, String [] selectors)
{code}
to
{code:java}
String getSchema(String resourceType, String slingResourceSuperType, String []
selectors)
{code}
Which then allows us to cache the {{GraphQLSchema}} using the resourceType,
supertype and selectors as a cache key.
Would this change be ok for your use cases? If yes we can ask on the Sling dev
list before making this breaking API change. Considering the graphql-core
module is version {{0.0.9}} such breaking changes can be ok unless someone
objects.
> Fully cache the GraphQLSchema objects
> -------------------------------------
>
> Key: SLING-10118
> URL: https://issues.apache.org/jira/browse/SLING-10118
> Project: Sling
> Issue Type: Bug
> Components: GraphQL
> Affects Versions: GraphQL Core 0.0.10
> Reporter: Thierry Ygé
> Priority: Major
>
> Currently in SLING-10085 the GraphQLSchema couldn't be cached due to wired
> resource.
> Thus it still need half the time to spend on building the schema, while
> generally the resource is only used to be passed later to the fetcher. As
> that resource then change, I suggested to wrap it via a proxy Resource
> implementation that would be passed instead of the real resource.
> That proxy will then use a map to lookup for the current resource used at
> execute/validate time. The key for the map is to use the current thread.
> I will submit a PR with the solution I suggest to use.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
