I'm getting very slow times on failures to resolve Boot snapshots
through the gradlePluginPortal (3-4 min build time). Moving it down
after repo.spring.io restores regular build times.
This is required as otherwise they're deactivated during the staging of
a release. We should reconsider our dependency on Spring Boot SNAPSHOTs
in our samples.
This commit refactors the project structure to regroup GraphQL web
support under the spring-graphql-web module, and move all the Spring
Boot support classes under a single graphql-spring-boot-starter one.
Right now, the starter module contains everything: classes for MVC,
WebFlux and Actuator support as well as required dependencies. We will
change that in the future.
This commit adds a sample application to the repository.
This application should not be published as part of the build.
In this application, we're trying to showcase the various features and
use cases with our Spring graphQL integration. We're mixing here data
fetchers backed by datastores or remote hypermedia APIs.
Closes gh-15
The GraphQL Spring Boot starters aren't actually necessary.
The typical GraphQL usage is really tied to the type of web application
you're building: Spring MVC or WebFlux.
Adding the `spring-graphql-web` dependency to the classpath is a signal
strong enough that we can configure additional endpoints into the web
application.
Closes gh-17
This commit merges the common, webmvc and webflux modules into a single
web module for supporting GraphQL with all Spring web frameworks.
We're working here with optional dependencies to build the support
for Spring MVC on one side and Spring WebFlux on the other.
Also, this commit updates the starter modules to adopt the official
naming convention. For now, starter modules will host both the
configuration infrastructure and the transitive dependencies to activate
support.
