Batch Requests / custom module interception before `graphqlPreHandler.Handler` ?

[sonewman]

Component(s)

router

Is your feature request related to a problem? Please describe.

I'm not sure if it's on your roadmap or not to support batch requests (i.e. an array of incoming graphql requests in POST body).

Obviously the typical functionality provided by apollo for example is fairly straightforward, requests are excuted concurently/in parallel (depending on choice of gateway/router) i believe it is not possible to use them with subscriptions or @defer, although i could confirm.

My team are currently reviewing our possible options for graphql schema management options for in house enterprise deployment and therefore are trying to gage how the available options could meet our current requirements.

At present we have some slightly more complex requirements and our execution of batch queries is slightly more intricate behaviour which we could potentially build in a custom module handler if we were able to intercept the request before the graphql operation was intercepted and manage passing on the individual queries as "pseudo" requests to the proceeding middleware.

One thing to mention, we do have plans to migrate our clients to use the more standardised approach to batch requests, but this could take time for us.

We also have some scenarios currently where it could be useful to be able to mount addition routes to other paths besides the graphql specific endpoints.

I'm not sure if you have any thoughts on this, i couldn't see a particularly straightforward way that the existing router could be mounted into a external http server (although this could be my personal oversight)

Describe the solution you'd like

Personal i think the standard batching implementation would probably be beneficial to most users who might find it more difficult to migrate from their existing solution to this router (i am aware the apollo router batching is specificially an "enterprise feature" however)

I also think the capability of being to intercept the request at a lifecycle hook prior to either parsing the request body or atleast before the body is marshalled into GraphQLRequest by the OperationKit/OperationProcessor would give additional capabilities for a wide array of other usecases

Describe alternatives you've considered

Another possible approach could be to make it viable to mount the router into an external http Handler. - that said while this would allow for even greater versitility this would introduce quite a few addition concerns, such as needing to provide context/arguments that would otherwise be determined at startup from arguments and configuration files and would probably require much more significant refactoring. So it's likely this is not the most feasible option.

Additional context

There are some other considerations which i can think of, such as how this should be treated in relation to otel, and how adding a possible inconsistent trace span encapsulating multiple executing operations might affect other parts of the cosmo system, in this respect I lack context.

One approach that could be considered might be use some form of enum to determine request type individual or batch and normalize the requests so that the resulting code always handles a slice of GraphQLRequest.

I am happy to fork and experiement to see how atleast the most basic approach could be made to introduce batching, testing against a local running version of cosmo, as well as experimenting with adding an earlier layer of middleware interception.

But it would be great to get your thoughts / feedback on these topics and the ideas suggested.

Thanks :)

[github-actions[bot]]

WunderGraph commits fully to Open Source and we want to make sure that we can help you as fast as possible. The roadmap is driven by our customers and we have to prioritize issues that are important to them. You can influence the priority by becoming a customer. Please contact us here.

[jensneuse]

My team are currently reviewing our possible options for graphql schema management options for in house enterprise deployment and therefore are trying to gage how the available options could meet our current requirements.

Hey, in such a case it's best if you contact our sales team and we organize a meeting with our Enterprise Support. You can then bring up your list of requirements and we can discuss synchronously how we're able to help.

[sonewman]

Should i create a new issue specifically for batch request support? I have made a stab at a first implementation of the standard behaviour that apollo and other implementations have (i.e. all queries/requests in the batch are are executed concurrently)

Initially i was concerned about the best way to add it to the code without requiring large refactoring, however I have managed to find a way by wrapping parts of the original implementation into callback.

Once i have tidied up my work i will raise a PR, as i think this would require extra tests and there might be extra considerations i've missed. But it would be awesome to get some feedback.