Currently, the GraphQL schema is exposed under /graphql/schema (so
relative to the main graphql endpoint) and is configurable with the
`spring.graphql.schema.printer.path` configuration property.
We think we should make the schema location more consistent to help
tools and various Gateway products. Also, we don't see right now a
strong use case for such a configuration property.
This commit removes the configuration property and sets the schema
location under `/graphql/schema`(`/graphql` being the main graphql path
configured by the application).
Closes gh-79
This commit improves gh-56 to scan schema locations for more well-known
file extensions, as previously only `*.graphqls` was supported.
We're now scanning for `*.graphqls`, `*.gqls`, `*.graphql`, `*.gql`.
Closes gh-56
Prior to this commit, the `spring.graphql.schema.location` would only
allow a single file as the source for the GraphQL schema.
This commit changes this configuration to
`spring.graphql.schema.locations` so that it accepts actual locations
(folders) and scans for `*.graphqls` files in those locations. All files
are parsed and merged as a single GraphQL `TypeDefinitionRegistry`.
Closes gh-56
The errorType field on GraphQLError is specific to GraphQL Java and when
serialized via GraphqlErrorHelper#toSpecification it becomes an
extension with the key "classification".
This commit ensures that we correctly deserialize back to errorType from
the "classification" extension but unfortunately that's limited to the
ErrorClassification enums that we know of.
This commit adds a new `spring.graphql.graphiql.path` configuration
property for setting the path to the GraphiQL UI page.
This change requires updates in the static HTML page to link the
JavaScript fetcher back to the actual GraphQL API endpoint.
Closes gh-70
Spring Data repositories that support Querydsl are now supported
as DataFetchers returning single objects and iterables including
projection support.
See gh-59
ThreadLocal values from a Servlet container thread maybe end up being
unnecessarily restored, e.g. if DataFetcher is invoked on the same
thread and then also removed, which then impacts the filter chain.
The ContextManager now saves the thread id when values are extracted
and ignores restore or remove calls if still on the same thread. This
should also be more optimal, avoiding ThreadLocal access if threads
aren't switched.
See gh-58
