-
Notifications
You must be signed in to change notification settings - Fork 317
Spring for GraphQL 1.4
This is a preview of the Spring for GraphQL 1.4 release, scheduled for May 2025.
Spring for GraphQL 1.4 now requires GraphQL Java 23.0 and Java DataLoader 4.0.0.
The GraphQL over HTTP draft specification is making good progress, so we have decided to fully align with it for our 1.4 release. Previous versions of Spring for GraphQL already supported the official "application/graphql-response+json", and it has been our default response media type for a while now.
Usually, GraphQL HTTP clients should expect 4xx/5xx HTTP responses if the server is unavailable, security credentials are missing or if the request body is not valid JSON. The remaining gap with this new specification was about the HTTP response status behavior in case of complete GraphQL engine failures. With recent changes, "application/graphql-response+json" responses will also use 4xx statuses if the GraphQL document sent by the client cannot be parsed or is considered invalid by the GraphQL engine. We are keeping the former behavior when clients request the "application/json" media type.
This change is a step towards a better understanding of GraphQL exchanges by platforms and tools in production, using the HTTP response status. This does not replace the need for dedicated GraphQL metrics and traces. See our existing observability support.
In addition to supporting the GraphQL over HTTP spec, we keep on improving our transport support. This new version brings performance improvements for Servlet-based applications, keep-alive for subscriptions over Server Sent Events and global HTTP timeout support with the new WebGraphQlInterceptor.
When a transport client closes the connection early, the cancellation signal is now propagated to data fetchers. This means that reactive data fetchers operations will be cancelled in-flight and further data fetching calls (blocking or reactive) will be avoided. This is done for you automatically and should save server resources in such cases.
Spring for GraphQL upgrades to Apollo GraphQL Federation 5.3.0 and refines our Federation support. We know support DataLoader arguments for @EntityMapping methods; this has been requested by GraphQL Java Kickstart developers migrating to our stack.
Also, our schema inspection feature now detects and reports federated entities not covered by any @EntityMapping method. This gives you the confidence that your entire schema is implemented by the application.
The Spring for GraphQL instrumentation creates Micrometer Observations for GraphQL requests and DataFetcher operations. Some data fetching operations are relying on batch loading calls to avoid the "N+1 problem". In previous generations, one would not see the difference between a "full" data fetching operation and one that simply delegates to DataLoader for loading efficiently entries in a batch operation.
This version adds a new "graphql.dataloader" observation that times data loading operations. With this change, recorded traces are much more precise as we clearly when the "N+1 problem" happens for a given GraphQL request.
Our reference documentation now better explains when and how local GraphQL contexts can be used in Spring applications with annotated controllers.