| tag | 88fdeb236203e72eaf1e67a92a1a44b5d7983672 | |
|---|---|---|
| tagger | Radu Cotescu <cotescu@adobe.com> | Tue Jul 07 11:38:28 2020 +0200 |
| object | 1b8134e744fe7349d95b901b9abe2b801921ee2c |
[maven-release-plugin] copy for tag org.apache.sling.graphql.core-0.0.4
| commit | 1b8134e744fe7349d95b901b9abe2b801921ee2c | [log] [tgz] |
|---|---|---|
| author | Radu Cotescu <cotescu@adobe.com> | Tue Jul 07 11:38:23 2020 +0200 |
| committer | Radu Cotescu <cotescu@adobe.com> | Tue Jul 07 11:38:23 2020 +0200 |
| tree | d256ed7becf76a80d228a305532a9aa3218ae411 | |
| parent | 9ff78709ffe70f6a360c55502d67202de920150c [diff] |
[maven-release-plugin] prepare release org.apache.sling.graphql.core-0.0.4
This module allows for running GraphQL queries in Sling, using dynamically built GraphQL schemas and OSGi services for data fetchers (aka “resolvers”) which provide the data.
To take advantage of Sling's flexibility, it allows for running GraphQL queries in three different modes, using client or server-side queries and optionally being bound to the current Sling Resource.
Server-side queries are implemented as a Sling Script Engine.
The current version uses the graphql-java library but that‘s only used internally. The corresponding OSGi bundles must be active in your Sling instance but there’s no need to use their APIs directly.
The GraphQL sample website provides usage examples and demonstrates using GraphQL queries (and Handlebars templates) on both the server and client sides.
As I write this, work is ongoing at SLING-9550 to implement custom GraphQL Scalars
This module enables the following GraphQL “styles”
The GraphQL requests hit a Sling resource in all cases, there's no need for path-mounted servlets which are not desirable.
Schemas are provided by SchemaProvider services:
public interface SchemaProvider {
/** Get a GraphQL Schema definition for the given resource and optional selectors
*
* @param r The Resource to which the schema applies
* @param selectors Optional set of Request Selectors that can influence the schema selection
* @return a GraphQL schema that can be annotated to define the data fetchers to use, see
* this module's documentation. Can return null if a schema cannot be provided, in which
* case a different provider should be used.
*/
@Nullable
String getSchema(@NotNull Resource r, @Nullable String [] selectors) throws IOException;
}
The default provider makes an internal Sling request with for the current Resource with a .GQLschema extension.
This allows the Sling script/servlet resolution mechanism and its script engines to be used to generate schemas dynamically, taking request selectors into account.
Unless you have specific needs not covered by this mechanism, there's no need to implement your own SchemaProvider services.
The GraphQL schemas used by this module can be enhanced using schema directives (see also the Apollo docs for how those work) that select specific SlingDataFetcher services to return the appropriate data.
A default data fetcher is used for types and fields which have no such directive.
Here's a simple example, the test code has more:
# This directive maps fields to our Sling data fetchers
directive @fetcher(
name : String,
options : String = "",
source : String = ""
) on FIELD_DEFINITION
type Query {
withTestingSelector : TestData @fetcher(name:"test/pipe")
}
type TestData {
farenheit: Int @fetcher(name:"test/pipe" options:"farenheit")
}
The names of those SlingDataFetcher services are in the form
<namespace>/<name>
The sling/ namespace is reserved for SlingDataFetcher services which hava Java package names that start with org.apache.sling.
SlingDataFetcher services can also be provided by scripts. This is experimental for now, see the tests for more info.
The <options> and <source> arguments of the directive can be used by the SlingDataFetcher services to influence their behavior.