Get ahead
VMware offers training and certification to turbo-charge your progress.
Learn moreOn behalf of the Spring for GraphQL team, I am pleased to announce the availability of 1.4.0-RC1, our last stop before the generally available release. In case you missed it, 1.4.0-M1 already shipped lots of new features and improvements.
You can read the full changelog for 1.4.0-RC1 and the upgrade notes on our wiki.
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 entries in a batch operation.
We added a new "graphql.dataloader"
observation that measures data loading operations.
graphql.datafetcher
observations are not recorded anymore for such operations.
With this change, recorded traces are much more precise as we clearly see when the "N+1 problem" happens for a given GraphQL request: "N data fetching operations" vs. "a single batch loading operation".
When a transport client (for example, an HTTP client) closes the connection early, the cancellation signal is now propagated to data fetchers. This was not the case previously, and data fetchers were completing their operations even if the client was gone.
From now on, 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. This inspired a feature request in graphql-java, and we're looking forward to using it in Spring for GraphQL.
Spring Boot 3.5.0-RC1 ships next week, so this will be the best way to try new features and suggest feedback before the official release.