graphql java 22 update #1967
graphql java 22 update #1967
Conversation
Apollo Federation Subgraph Compatibility Results
Learn more: |
...deration/src/test/kotlin/com/expediagroup/graphql/generator/federation/data/TestResolvers.kt
Show resolved
Hide resolved
| @@ -71,7 +71,7 @@ type Query @extends | |||
|
|
|||
| type Review { | |||
| body: String! | |||
| content: String @deprecated(reason : "no longer supported, replace with use Review.body instead") | |||
| content: String | |||
There was a problem hiding this comment.
why the change in schema?
There was a problem hiding this comment.
why the change in schema?
the @deprecated directive is hidden from the ServiceSDLPrinter
i don't know why with the previous graphql-java version the test was passing though.
...ain/kotlin/com/expediagroup/graphql/generator/execution/FlowSubscriptionExecutionStrategy.kt
Outdated
Show resolved
Hide resolved
...ain/kotlin/com/expediagroup/graphql/generator/execution/FlowSubscriptionExecutionStrategy.kt
Outdated
Show resolved
Hide resolved
| @@ -31,4 +31,4 @@ details on the supported configuration properties. | |||
| | graphql.subscriptions.keepAliveInterval | **Deprecated**. Keep the websocket alive and send a message to the client every interval in ms. Defaults to not sending messages | null | | |||
| | graphql.subscriptions.protocol | WebSocket based subscription protocol. Supported protocols: APOLLO_SUBSCRIPTIONS_WS / GRAPHQL_WS | GRAPHQL_WS | | |||
| | graphql.batching.enabled | Boolean flag indicating whether to enable custom dataloader instrumentations for 1 or more GraphQL Operations | false | | |||
| | graphql.batching.strategy | Configure which custom dataloader instrumentation will be used (LEVEL_DISPATCHED or SYNC_EXHAUSTION) | LEVEL_DISPATCHED | | |||
| | graphql.batching.strategy | Configure which custom dataloader instrumentation will be used | SYNC_EXHAUSTION | | |||
There was a problem hiding this comment.
since we only have single data loader batching strategy do we really need this config?
There was a problem hiding this comment.
i would like to keep the door open for future dispatch mechanisms, SYNC_EXHAUSTION works but comes with a price, needs to hold state of each field, and memory usage could be a concern, in the future we could try to have a different dispatch mechanism that will use less memory maybe.
There was a problem hiding this comment.
The keyword is "might" -> Unless there is something already in the works/roadmap I am unsure if there is ever going to be one so I'd just drop it and reintroduce it later on if needed.
There was a problem hiding this comment.
Also I find graphql.batching.enabled property confusing -> we always support batching so this only applies to dataloader config (as per comments). Wondering whether this should be deprecated in favor of something like graphql.loader.batching.strategy = SYNC_EXHAUSTION | NONE (NONE would imply current graphql.batching.enabled = false)
There was a problem hiding this comment.
we always support batching
we added graphql.batching.enabled in order to opt out from the built-in "by level" graphql-java dataloader instrumentation.
There was a problem hiding this comment.
yeah we added it originally for the custom data loaders -> just wondering whether we should revisit this property naming for the next major
...ain/kotlin/com/expediagroup/graphql/generator/execution/FlowSubscriptionExecutionStrategy.kt
Outdated
Show resolved
Hide resolved
### 📝 Description Follow up to #1967 to use an official graphql java release.
📝 Description
waiting for an official release of this PR graphql-java/graphql-java#3571
UPDATE:
next graphql-java update will be on July,
https://github.com/graphql-java/graphql-java/milestone/69
they helped us releasing from this branch
graphql-java/graphql-java#3571
which will unblock us.
https://github.com/graphql-java/graphql-java/releases/tag/v22.0