Support for apollo batching

[macnibblet]

It would be awesome if we could detect batch operations based on a header and then parse the incoming request as an array of operations or a single operation.

[macnibblet]

This is a really really ugly proof of concept, but it actually works.
https://gist.github.com/macnibblet/8c25cd7964c6c28fe09c40126424032c

Things one probably wants to take into account is the number of concurrent operations running.
I'm thinking a worker pool per request is probably a better solution, but not entirely sure.

Secondly, I have no idea how the tracing gets affected by this code.

Thirdly, No mutexes around the responses slice, https://stackoverflow.com/questions/49879322/can-i-concurrently-write-different-slice-elements not sure if it's a good idea but too lazy to abstract away the boilerplate

[mathewbyrne]

Thanks @macnibblet — this is a great reference for anyone that is interested in implementing this now. It does highlight that handler could probably do with a refactor to make it a bit more swappable.

[macnibblet]

@mathewbyrne If someone can confirm the tracing works with the way I have implemented it now I have no problem turning it from a proof of concept to production worthy code.

I could use this in production for a few applications we are running with this awesome library.

[macnibblet]

@vektah Do you have any comments on how the tracing should work when batching? Else ill update my POC and create a merge request.

[vektah]

I don't think batching can happen concurrently without a bit more work to establish sync boundaries.

Consider a batch that looks like this:

query q1 { user(id: 1) {name} }
mutation m1 { setName(id: 1, name: "foo") { name } }
query q2 { user(id: 1) {name} }
mutation m2 { setName(id: 1, name: "bar") { name } }
query q3 { user(id: 1) {name} }

I would expect to get back

q1: "previous"
m1: "foo"
q2: "foo"
m2: "bar"
p3: "bar"

The suggested implementation would likely do something very different.

I'm not sure how apollo tracing + batching should work, someone would need to fire up a server and have a look at whats in the extensions. It probably keeps each req/resp separate.

Also make sure you base any work on the next branch, rebasing between the two is painful.

[macnibblet]

@vektah AFAIK you are not allowed to mix queries and mutations?

Regards to the tracing, do we want to split each operation into a single request or have them under the same request?

[vektah]

@vektah AFAIK you are not allowed to mix queries and mutations?

Ahh right, lets make sure we have some validation covering that.

Regards to the tracing, do we want to split each operation into a single request or have them under the same request?

I think that makes sense, still worth having a look at what apollo server does with tracing turned on. apollo tracing is returned in the extensions key of the response, so I imagine its per query/mutation.

[xzyfer]

We're interested in this feature too. Happy to collaborate on an implementation.

[sneko]

Hi everyone, I'm also interested in this feature 😀

Any news on the advancement?

Thank you,

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[frederikhors]

No stale.

[wegged]

Interested in this as well

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[frederikhors]

Nope, stale.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[sneko]

Still interested 😉

[frederikhors]

Can we disable stale for some issues?

[xzyfer]

Would this be easier given the recent handler refactor?

[gbartlett]

yeah would love to see this as well!

[maxbeatty]

I'm interested in funding/sponsoring this enhancement. I'm not sure how it would work through the 99designs organization but happy to work with individuals directly. If anyone else is interested in pitching in, add an 👀 reaction!

[ghost]

I would like this feature as well. To work better with the nautilus gateway batching https://gateway.nautilus.dev/advanced/batching

[xzyfer]

@vektah AFAIK you are not allowed to mix queries and mutations?

Digging around the apollo-server implementation this limitation does not appear to be codified. From looking through some issues it appears this behaviour is intentional

batching order isn't a guaranteed order so mutation executed in batch will all run in parallel aside from an ordered serial list of mutations. I would recommend not batching with mutations on the client

Essentially it's the client responsibility to not create batched requests that would result in undesirable race conditions.

More context

• Batched requests' mutations should be executed serially? apollographql/apollo-server#531
• batching implementations should (optionally?) run queries in parallel apollographql/apollo-server#176

[Sh1d0w]

Any plans to implement that?

[sneko]

Hi @lwc , it seems you are the latest 99designs team member who contributed over the last months to this project.

Do you know if there is any interest from your team for this batching feature?

Thank you,

[zdraganov]

Happy to lead a meeting about implementing the feature, if there are people interested in contribution.

[jtag05]

I'm seeing this has gone fairly quiet for the last year. Is this something you all are still considering supporting? I'd be happy to contribute.

[Kagenuge]

Interested in the feature! 🚀

[arthurvaverko]

looks like someone already made a decent extension .. im gonna test it and let you know :)
https://github.com/davewhit3/gqlgen-batching/tree/master

[zdraganov]

Went over the extension and it lgtm.