Samuel Vazquez

>Doesn't the current of https://github.com/ExpediaGroup/graphql-kotlin/pull/1568 implementation break batching as a whole when not using DataLoaders in a FederatedTypeResolver The idea behind the change was to also achieve consistency across other...

we have 2 options: 1. Manually set the default parser options `ParserOptions.setDefaultParserOptions(ParserOptions.newParserOptions().maxTokens().build())` 2. specify parserOptions in the `GraphQLContext` https://github.com/graphql-java/graphql-java/blob/master/src/main/java/graphql/ParseAndValidate.java#L64

Hello, have you just using the combination of ```kotlin @GraphQLIgnore @Autowired ``` in your resolvers ? i guess the goal here is to be less verbose ?

sounds good, will work on adding the annotation.

👀 using a different strategy to dispatch data loader registry could help to solve this issue instead of doing it by level, do it like original dataloader impl of js...

This new custom instrumentation does keep track of state of each `ExecutionStrategy` so more computation will be needed, but that better because it will optimize the amount of possible IO...

@holzerch v7 alpha version does not contain the changes @dariuszkuc mentioned >Kotlin v1.7.21 and kotlinx.serialization v1.4.1 ([link](https://github.com/ExpediaGroup/graphql-kotlin/blob/master/gradle.properties#L17-L20)) we can probably release another alpha or you can publish to your local...

> 1. Minimize redundant Query Planning across a fleet of routers. The advantage of having a query planning service is that it can be shipped as a sidecar, or as...

created this draft PR https://github.expedia.biz/weaver/weaver-loom-router/pull/39 to add support for batching at router_service layer.

related issue: https://github.com/ExpediaGroup/graphql-kotlin/issues/1611 @maxpiepenbrink contributions are always welcomed!.