Skip to content

Commit

Permalink
README about DataFetcher definitions
Browse files Browse the repository at this point in the history
  • Loading branch information
@bdelacretaz
bdelacretaz committed Apr 17, 2020
1 parent 25cbb95 commit 0c9db2d
Showing 1 changed file with 34 additions and 5 deletions.
39 changes: 34 additions & 5 deletions graphql-scripting/README.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -19,12 +19,41 @@ implement any suitable dynamic mechanism to provide it.

----

## Next Steps
## Decorating the schemas with DataFetcher definitions

With dynamic schemas, I think the mapping of types and/or fields to DataFetchers belongs in them.

We can use structured comments in the schemas for this so that they stay syntactically valid.

Here's an example where `## fetch:` comments are used for these definitions:

This comment has been minimized.

Sign in to view

Copy link
@stefangrimm

stefangrimm Apr 21, 2020 •
edited
Loading

Contributor

After experimenting a bit with this syntax, I'd like to suggest the following adjustment:

Comment-based annotations should be placed before the field definition. In that case, we can leverage graphql-java to do the general parsing and use FieldDefinition.getComments() to access the comments. This doesn't work if we use the suggested "suffix-based approach, as the comments would be attributed to the wrong field definition.

If we stick to the suggested syntax, we would probably have to implement our own GraphQL (pre-) parser, which is something I would like to avoid at almost any cost.

A data fetcher would then defined like this:

type Query {
  # Use the test/pipe data fetcher for fetching current resource
  ## fetch:test/pipe
  currentResource: SlingResource
}

@bdelacretaz WDYT?

This comment has been minimized.

Sign in to view

Copy link
@stefangrimm

stefangrimm Apr 21, 2020

Contributor

Another alternative was to decouple the fetcher definition from the location in the schema by adding type and field name to the fetcher definition, e.g.

## fetch:Query.currentResource:test/pipe
## fetch:Model.anotherResource:test/pipe2

type Query {
  currentResource: SlingResource
}

type Model {
  anotherResource: SlingResource
}

This comment has been minimized.

Sign in to view

Copy link
@bdelacretaz

bdelacretaz Apr 21, 2020

Author Member

Thank you for these comments, I wasn't aware of use FieldDefinition.getComments() but it's a great idea, makes things simpler to implement. Looking at the source code of that class it uses a DataFetcherFactory that we might be able to hook up for this. I'll be working on this later today, will keep this in mind and will keep you posted!

type Query {

# Use the 'test:pipe' Fetcher where "test" is a Fetcher namespace,
# and pass "$" to it as a data selection expression which in this
# case means "use the current Sling Resource".
currentResource : SlingResource ## fetch:test/pipe $

}

type SlingResource {
path: String
resourceType: String

# Use the "test:digest" DataFetcher with the "md5" fetcher option
# and pass "$path" as its data selection expression
pathMD5: String ## fetch:test/digest/md5 $.path

# Similar with different fetcher options
pathSHA512: String ## fetch:test/digest/sha512,armored(UTF-8) $.path
}

A default `DataFetcher` is used for types and fields which have no `## fetch:` comment.

This is **not yet implemented** at commit 25cbb95d, there's just a basic parser for the above
fetch definitions.


* This is just a rough prototype for now, in "the tests are green, who cares?" style.
* We'll probably need to invent a way to specify which `DataFetchers` to use in the schemas, for example decorating
them with information on how to select a suitable `DataFetchers` OSGi service based on service properties.

## Multiple GraphQL endpoint styles

This module enables the following GraphQL "styles"
Expand Down

0 comments on commit 0c9db2d

Please sign in to comment.