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
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
Show map-based batch loading first which is easier to implement without
having to order results.
Use JUnit named arguments in BatchMappingInvocationTests.
See gh-130
Rename AnnotatedDataFetcherConfigurer -> AnnotatedControllerConfigurer,
since handler methods are now not only data fetchers but also
batch loaders.
Move DataFetcherHandlerMethod and BatchLoaderHandlerMethod into the
support package next to AnnotatedControllerConfigurer where they're used.
See gh-130
Prior to this commit, the `@Argument` annotation would support two
attributes: `required` and `defaultValue`, specifying whether arguments
should be considered as required and default values to use if they're
not present.
This can be problematic as this can already be specified at the schema
level.
To avoid duplication and invalid setups betweens schema and Controllers,
this commit removes those attributes in favor of the schema definition.
Closes gh-150
This commit adds a new `"graphql.request.datafetch.count"` distribution
summary metric for counting the number of data fetching calls per
request.
Closes gh-146
Prior to this commit, a Spring GraphQL application would need to
implement `WebMvcConfigurer` or `WebFluxConfigurer` to register a
specific CORS configuration and map it to the GraphQL endpoint.
This commit adds new configuration properties under the
`spring.graphql.cors.*` namespace that helps configuring CORS for the
GraphQL endpoint.
Closes gh-26
This commit introduces versions as dynamic attributes in the reference
docs. This also fixes a few incomplete references that were logging
warnings during the documentation build.
The adapter aims to:
- simplify the common case of synchronous resolution to a single error
- support ThreadLocal context propagation on an opt-in basis
This replaces the SyncDataFetcherExceptionResolver and removes the need
to propagate ThreadLocal context to every resolver.
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
