Rename "headers" to "responseHeaders" and clarify those work for HTTP
request queries but not for queries over a WebSocket session.
Update getter for response headers to return a read-only wrapper.
Provide only one public constructor without headers.
See gh-42
Use getters so the base RequestInput is usable for JSON serialization,
e.g. for the testing support.
Remove WebSocketMessageInput which only had an extra requestId and
add that to WebInput instead.
See gh-42
Rename to GraphQLService to make it more clear it is a layer below
the specific transport such as HTTP endpoints.
Add WebGraphQLService sub-interface for query execution in web
environment with a WebInterceptor chain.
See gh-42
This commit fixes the build configuration for annotation processing.
The configuration metadata is now being generated and packaged with the
starter module.
Fixes gh-33
Prior to this commit, the WebSocket endpoint (MVC or WebFlux) would be
enabled by default. In the case of MVC, the presence of
`spring-websocket` and the required dependencies was an additional hint
that could enable/disable this support depending on the application.
This commit changes the websocket path configuration so that it doesn't
hold a default value anymore. Configuring this property will trigger the
WebSocket support.
Right now developers cannot configure it to be the same as the
`spring.graphql.path`, but this will be solved in #30.
This commit also revisits the configuration properties namespace for
clarity, moving the websocket bits under their own section.
Closes gh-31
This commit ensures that the WebSocket auto-configuration is guarded
with class conditions on WebSocket classes (from the javax API and the
spring-websocket artifact).
This prevents issues where application without such dependencies are
failing at startup.
Decouple from HandshakeInfo which is WebFlux specific.
Rename the class to WebSocketMessageInput since it's per message.
Use more specific name for id field based on the protocol.
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
This commit adds a very simple graphiQL integration: we're shipping the
project with a sample graphiQL `index.html` page that's relying on CDNs
to display the explorer.
We're also plugging in that resource at the graphQL endpoint location,
responding to GET requests. This is not a problem since for now we're
only considering POST requests to the endpoint for actual queries.
Closes gh-12
The graphQL spec requires that the `variables` object should not be
null. Prior to this commit, the `Map#getOrDefault` call would not
prevent that since it returns the value associated with the key, if
defined, or the default value. In our case the key is defined but the
value is null.