Hanusz Leszek

> I think it's a good idea to start with the sync batch first that receives a collection of documents and returns another collection with the results. I'll open a...

> Yes, the design would be to add a `Transport#execute_batch` and a `Client#execute_batch`. In the beginning just to the sync transport, raising a non-implemented error for the rest. :+1: >...

Yes, using a dataclass seems to be a much better option indeed.

but I would use something like `Operation` instead of `GraphQLQuery` to better correspond to GraphQL terminology.

@itolosa I made the PR #436 to implement the auto batching with sync transports, with the inspiration of your code. Could you please take a look? You can test it...

Let's talk about use cases. ### Use case 1: automatic batching What is the main use for automatically batching GraphQL requests together? In javascript, for a modern web page, you...

Sure, why not make a new transport named `AIOHTTPWebsocketsTransport`. I'll accept a PR if it is well-tested and comes with 100% test coverage.

I think you're mixing two different things. The HTTP callback protocol that you first linked is different than the Multipart HTTP protocol (which is on the next page of the...

> Yep, you're correct about the differences... also for context, I'm a Solutions Architect at Apollo. 😄 Oops :laughing: > I don't know of a public backend currently... but I...

> If you need a backend for testing this I can make a an example with Strawberry (I have a PR open to add multipart support: [strawberry-graphql/strawberry#3076](https://github.com/strawberry-graphql/strawberry/pull/3076)) That would be...