Your app posts every GraphQL query to the single endpoint /graphql. In Mock Service Worker (MSW), why would you write graphql.query('GetUser', resolver) rather than an http.post('/graphql', resolver) handler?

## The URL stops being the identity REST puts the identity of an operation in the request line: `GET /api/users/7` says what you want and what you intend to do with it. That is exactly what a network-level mock matches on. GraphQL moves that identity into the request body — one endpoint, almost always `POST /graphql`, with the document and variables in the payload. The routing information a URL-based matcher relies on is gone. So a handler written as `http.post('/graphql', …)` matches every operation the app will ever issue. To make it useful you would read the body, look at the document or the `operationName` field, and branch: ```js http.post('/graphql', async ({ request }) => { const { operationName, variables } = await request.json() if (operationName === 'GetUser') return HttpResponse.json({ data: { user: { id: variables.id } } }) // …a growing else-if chain }) ``` That works, and it is precisely the boilerplate the `graphql` namespace exists to remove. ## What graphql handlers match on ```js import { graphql, HttpResponse } from 'msw' export const handlers = [ graphql.query('GetUser', ({ variables }) => { return HttpResponse.json({ data: { user: { id: variables.id, name: 'Ada' } }, }) }), graphql.mutation('UpdateUser', ({ variables }) => { return HttpResponse.json({ data: { updateUser: { id: variables.id } } }) }), ] ``` MSW inspects the intercepted request, extracts the operation, and matches on two things: the operation *type* (query or mutation) and the operation *name*. The resolver receives the parsed `variables`, which is usually what a test wants to assert on — that the component sent the right id, the right page size, the right filter. `graphql.operation()` matches any operation, which is the catch-all when you want one blanket response or a passthrough. ## You still own the envelope MSW does not execute a schema. It hands back whatever you return, so you must return the GraphQL response envelope yourself — a top-level `data` object shaped like the query's selection set. A common early mistake is returning the entity directly (`HttpResponse.json({ user })`), which the client then reads as a response with no `data` field. The same envelope is how you test failure paths: GraphQL conventionally answers with HTTP 200 and an `errors` array, so a handler returning `HttpResponse.json({ errors: [{ message: 'Not found' }] })` exercises the client's error branch far more faithfully than a 500 would, because a 500 is not what the real server does. Because you are writing the envelope by hand, nothing checks it against the schema — an over-fetched or misspelled field in your fixture will sail through the mock and only fail against the real API. Deriving fixtures from the schema is the countermeasure, and it is a separate discipline from handler matching. ## Two gotchas **Anonymous operations.** A document written as `query { user { id } }` has no name, so a name-based handler has nothing to match. If the client library strips or omits operation names, or a developer writes an anonymous document, the handler silently does not apply. Naming every operation is good practice anyway — it is what makes operations legible in server logs and traces — so the fix is on the client side. **Multiple endpoints.** If the app talks to two GraphQL services, an operation name alone might be ambiguous or, worse, the same name might exist on both. `graphql.link('https://api.example.com/graphql')` returns a scoped namespace whose `query` and `mutation` handlers match only requests to that URL, restoring the endpoint dimension when you actually need it. ## The transferable principle The wider lesson survives any particular mocking tool: **match a request at the level where its identity actually lives.** For REST that is method plus path. For GraphQL it is the operation inside the payload. For an RPC-over-POST API it may be a method field in the body or a header. When your mocking layer only offers URL matching for a protocol whose identity is not in the URL, you end up hand-writing a dispatcher, and that dispatcher becomes an untested piece of test infrastructure with its own bugs. Choosing a matcher that speaks the protocol's own vocabulary keeps the fixture readable and keeps each test's override narrow — you override one operation, not the whole endpoint.