Multi-Operation Requests

## The shape on the wire An ordinary GraphQL request over HTTP is a POST whose body is a JSON **map**: `query` carries the executable document, `variables` a map of values, `operationName` the name of the operation to run when the document defines more than one, and `extensions` anything else the server has agreed to read. Transport-level batching changes exactly one thing about that picture: the body is a JSON **array** whose elements are those same maps. ```json [ { "query": "query CampaignBanner($slug: String!) { campaign(slug: $slug) { title goalPence } }", "variables": { "slug": "winter-appeal" } }, { "query": "query DonorProfile($id: ID!) { donor(id: $id) { displayName totalGivenPence } }", "variables": { "id": "dnr_8814" } } ] ``` The server executes each element and answers with a JSON array of the same length in the same order. Everything inside a member is ordinary: it is parsed, validated and executed as an independent operation against the same schema, and it produces its own complete result envelope. The batch is a wrapper around several requests, not a way of fusing them into one bigger operation. ## Matched by position, because nothing else can match them The convention carries no correlation identifier. There is no `id` key on a member and no echo of the operation name in the result, so the only thing tying a result to the operation that produced it is its index in the array. A batching client library keeps the pending callers in a list and resolves the caller at index *k* with element *k* of the response. That makes ordering a hard contract rather than a nicety: a server that reordered members, dropped one, or collapsed two identical members into a single result would silently hand a donor profile to the code that asked for a campaign banner. ## What the specifications actually say about it: nothing This is the part interviewers are usually probing. The GraphQL specification describes the type system, documents and the execution algorithm, and deliberately says nothing about HTTP. The GraphQL over HTTP specification - still a working draft rather than a released edition - is the document that defines the request, and it defines the body as a **map** with those keys, sent by POST, or as URL-encoded parameters on a GET for a query. There is no array form in it and no member-level status semantics, because the array body simply is not in scope. So transport batching is a widespread convention with no normative text behind it. There is no capability negotiation either: no header advertises it and no introspection field reports it. A client either knows from documentation that the server accepts an array body, or discovers that it does not when the server fails to find `query` in what it took to be a map and answers with a request error. ## Why clients started doing it A component-driven page tends to issue several small operations within a few milliseconds of each other as its tree mounts. Each one costs request and response headers, a serialization pass and, on a transport that cannot carry requests in parallel, a place in a queue. Collecting whatever was issued inside a short window - single-digit milliseconds is typical - and sending it as one body removes most of that per-request overhead. The argument was much stronger when connections could not multiplex. Where the transport can carry many requests in parallel, the round-trip saving shrinks to the header and framing overhead, and the costs described elsewhere in this leaf - one status for many operations, one latency for many operations, one cache key for many operations - stop being obviously worth paying. ## Three different things get called "batching" Being precise here is most of the interview value: - **Transport-level batching**: several operations in one HTTP body, as an array. Several results come back. This is the subject here. - **Several operations in one document**: one `query` string that defines more than one named operation, with `operationName` choosing which to run. The server executes exactly one of them and returns one result. - **Batching backend calls inside one operation**: the per-request load-batching pattern that collapses many repeated backend calls made during a single execution. One operation, one result, fewer database round trips. An interviewer who asks "how do you batch in GraphQL?" without qualifying it usually means the third. Saying which one you are answering, and why they are unrelated, is the answer that lands. ## What the server has to decide Accepting an array body forces choices the specification does not make for you: whether members execute concurrently or in sequence; what the maximum member count is and what happens beyond it; whether members share one request-scoped context or each gets a fresh one; and whether the response array is guaranteed to preserve request order, which clients will assume regardless. Authentication is evaluated once for the HTTP request, but authorization is still per member, because each member is its own operation selecting its own fields.