For a completely generic SortStrategy we can't provide any concrete
support we know neither the input structure nor the Object structure.
At best, a nearly empty argument resolver, which is not any better
than providing your own custom argument resolver.
Hence, SortStrategy is now explicitly based on Spring Data's Sort,
which enables us to provide concrete support with a base class.
See gh-620
ConnectionTypeVisitor to decorate DataFetchers for Connection fields
in order to adapt Window, Slice, and others to Connection.
A ScrollRequest controller method argument to inject the ScrollPosition
and the number of elements requested.
SortStrategy for an application to customize how to extract sort
details from GraphQL arguments.
See gh-620
Because performing the schema mapping inspection on the
`TypeDefinitionRegistry` could be too early in the process, this commit
uses instead the `GraphQLSchema` instance directly for the inspection.
Other extension points could indeed contribute more to the schema before
it's fully built.
As for querying for DataFetcher instances, the inspector keeps using the
`RuntimeWiring` instance right after Spring for GraphQL contributed to
it. After that, data fetchers could wrapped by other extensions,
preventing it from getting the type information we need.
This also moves the `TypedDataFetcher` interface to a different package
to prevent a package tangle, and renamed as `SelfDescribingDataFetcher`
to enable further extension and to be more descriptive.
This changes the report format to keep it on a single line.
Closes gh-386
Prior to this commit, a Spring for GraphQL application could be started
with a schema and an incomplete set of data fetchers, as the schema
would describe:
* Queries/Mutations/Subscriptions that are not backed by any
`@Controller` method, any Spring Data repository nor any custom
`DataFetcher`
* type fields that are not backed by any Java Type property nor any
registered `DataFetcher`
This problem can be noticed at runtime when a request is sent to the
API. The response can contain a `null` field where data was expected, or
even a GraphQL error because the field was non nullable.
This often happens during development time while developers are
implementing the schema.
This commit adds a new `SchemaInspector` type that visits the GraphQL
schema during the startup phase and looks into the `RuntimeWiring` for
registered `DataFetcher` instances. Because data fetchers can be simple
lambdas and do not require to expose a concrete return type, this also
introduces a new `TypedDataFetcher` interface that returns a
`ResolvableType`. This type is only declared by the data fetcher
implementation, but does not necessarily reflects the concrete type
of the returned instances.
This inspection is best effort and has known limitations, such as Union
types (those will not be inspected). Because of those, the inspection
will not fail the application startup.
The `SchemaInspector` collects all missing fields into a report and its
output is logged at startup at the INFO level. As a first step, the
inspector is package private and is only used by the
`DefaultSchemaResourceGraphQlSourceBuilder`. The inspection cannot be
disabled nor customized. We can expand this feature in future releases
as the team collects feedback from the community.
Closes gh-386
