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
This is unlikely to happen as authentication happens prior to reaching
the GraphQL APIs. However, a user may decide to implement security within
GraphQL as it is possible to do through a Spring Controller.
Use ThreadLocalAccessor, the main API for ThreadLocal value management,
to state where this is supported, which is in Spring MVC, GraphQL
applications.
Improve Javadoc in related contracts as well including a minor
refactoring in ContextManager.
Right now the Spring JavaFormat and Checkstyle arrangement doesn't work
for the Spring GraphQL source code.
This commit disables the dedicated Gradle conventions until we find a
better solution.
