This commit configures all `DataLoaderRegistrar` application components
with the `GraphQlService`. This allows applications to contribute
`DataLoader` instances without using the annotated-controller
programming model.
Closes gh-189
Prior to this commit, the main GraphQL auto-configuration would be
guarded with a condition on a `GraphQlSource` bean being missing. While
we want to prevent the auto-configuration from registering such a bean
if the user configuration already did so, we should still contribute the
`GraphQlProperties` bean to the context, as it is required for other
purposes.
This commit moves the condition directly on the bean method to avoid
this.
Fixes gh-186
Prior to this commit, the `WebInput` would hold an `id` attribute that
correlate the request and response messages on a multiplexed connection.
This commit moves this concept directly to the `RequestInput` so that it
can be used as an `ExecutionId` for all types of transports, if
availble.
This id was already set on the `WebInput` in the WebFlux case with the
id coming from the exchange, but it also creates an id and set it for
the MVC case. This id is then propagated to GraphQL's `ExecutionInput`.
See gh-183
This commit upgrades the experimental starter to Spring Boot 2.6.0-RC1
and aligns all dependency versions to the Spring Boot dependency
management in 2.6.
This commit also removes temporary workarounds in the testing support or
in declared dependencies now that we've moved to 2.6.
While we're now using Spring Boot 2.6 as a reference version for this
project, the baseline didn't change and this commit documents the
requirements for this project; the Spring Data version, for our QueryDSL
support, is a specific example of that.
Fixes gh-181
Add GraphQlSetup that provides a unified workflow for test setup
including the creation of a GraphQsSource, a GraphQlService, a
WebGraphQlHandler, and/or HTTP handlers. The workflow also helps to
collect input (schema, data fetchers) in ways that are convenient
for testing purposes.
Add GraphQlResponse wrapper around ExecutionResult to provide access to
data with JSONPath and type conversion, along with convenience methods
to verify errors.
Batch loading functions registered via BatchLoaderRegistry now have
Reactor Context propagated to them and also have access to the
GraphQLContext from the ExecutionInput.
Closes gh-173
After the introduction of the `@GraphQlTest` annotation, this commit
adds further refinements to the testing infrastructure.
Now, `@GraphQlTest` is completely independent of any web framework and
contributes a `GraphQlTester` component.
`@SpringBootTest` integration tests with mock servers only require an
`@AutoConfigureWebGraphQlTest` to get a `WebGraphQlTester` component.
Closes gh-75
We now request only property paths from the repository query
that are requested through a GraphQL query if the result type
is not a projection. That reduces the amount of data being
retrieved from the underlying data store.
See gh-168
Prior to this commit, we could only test Spring GraphQL applications
with a complete application - all application and infrastructure
components were involved. While using `@SpringBootTest` is often useful
for complete integration tests (with or without a live running server),
we often want to write lean integration tests and test slices of our
application.
Just like `@WebMvcTest` or `@WebFluxTest`, this commit introduces the
support for `@GraphQlTest`. This annotation helps us to test a
particular slice of our application: a hand-picked selection of
`@Controller`, plus `RuntimeWiringConfigurer` and `WebInterceptor`
beans.
Other `@Component` must be imported or mocked for those tests.
This commit also refactors the existing auto-configuration to enable
this use case. The `WebGraphQlHandlerAutoConfiguration` now holds the
required components for `@GraphQlTest`, while other web-related
auto-configurations bring the web framework and transport
infrastructures.
Closes gh-75
