Closed renovate[bot] closed 3 months ago
superseded by https://github.com/apollographql/federation-jvm/pull/395
Because you closed this PR without merging, Renovate will ignore this update. You will not get PRs for any future 22.x
releases. But if you manually upgrade to 22.x
then Renovate will re-enable minor
and patch
updates automatically.
If you accidentally closed this PR, or if you changed your mind: rename this PR to get a fresh replacement PR.
This PR contains the following updates:
21.3
->22.0
Release Notes
graphql-java/graphql-java (com.graphql-java:graphql-java)
### [`v22.0`](https://togithub.com/graphql-java/graphql-java/releases/tag/v22.0): 22.0 We are pleased to announce the release of graphql-java v22.0. Thanks to everyone in the community who contributed to the release, whether that was code, helping to report issues, or participating in discussions. This is a **breaking change** release. The graphql-java team takes breaking changes very seriously but in the name of performance we have made some significant breaking changes in this release. ### Major Performance Changes Past releases have been very much performance focused and this one is no different. However, this release is aiming to reduce memory pressure more than reduce pure CPU usage. When the graphql-java engine is running, if it produces less objects it will ultimately run faster because of reduced memory pressure and less garbage to collect. The engine has been changed in two major ways that reduce memory pressure. #### ExecutionResult wrapping The first was that all values that come back got wrapped internally into a `ExecutionResult` object where the `data` attribute was the value. This was a carry over from some very early GraphQL code but was unnecessary and hence has been removed. The follow on effect of this is that some `graphql.execution.ExecutionStrategy` protected methods and `graphql.execution.instrumentation.Instrumentation` methods used to receive and return `ExecutionResult` values and no longer do, which is an API breaking change. We have made this breaking changes in the name of memory pressure performance. #### CompletableFuture wrapping The second major change is that the engine no longer exclusively uses `java.util.concurrent.CompletableFuture`s when composing together results. Let us explain the past code first so we can discuss the new code. `CompletableFuture` is a fantastic construct because it represents a promise to a value and it can also hold an exceptional state inside itself. Async programming with `CompletableFuture` is viral. If stage 1 of some compute process returns a `CompletableFuture` then stage 2 and 3 and 4 are likely to as well to ensure everything is asynchronous. We use to take values that were not asynchronous (such as DataFetcher that returned a simple in memory object) and wrap them in a `CompletableFuture` so that all of the other code composed together using `CompletableFuture` methods like `.thenApply()` and `.thenCompose` and so on. The code is cleaner if you use all `CompletableFuture` code patterns. However many objects in a GraphQL request are not asynchronous but rather materialised objects in memory. Scalars, enums and list are often just values immediately available to be used and allocating a `CompletableFuture` makes the code easier to write but it has a memory pressure cost. So we have sacrificed cleaner code for more memory performant code. graphql-java engine `graphql.execution.ExecutionStrategy` methods now just return `Object` where that object might be either a `CompletableFuture` or a materialised value. ```java private Object /*CompletableFutureConfiguration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by Mend Renovate. View repository job log here.