GraphQL Doesn't Kill the Need to Mock — It Just Moves It

One of GraphQL's selling points is that a client can ask for exactly the fields it needs in one request, instead of the REST pattern of hitting several endpoints and discarding what you don't want. That's a genuine improvement for a specific problem (over-fetching, under-fetching, the N+1-over-HTTP pattern), and it's sometimes mistakenly assumed to also simplify mocking — when what it actually does is move the complexity somewhere else.

Why "just return this JSON" doesn't work as cleanly

A REST mock's job is straightforward: this method and path returns this body. A GraphQL endpoint is almost always a single URL (POST /graphql) that accepts a query describing exactly what the client wants, with the actual response shape varying per query — the same endpoint might return { user { name } } for one call and { user { name, orders { id, total } } } for another. A mock that just returns one fixed body for "any request to /graphql" doesn't work at all, because the client's query, not the URL, determines what a real server would send back.

To mock GraphQL meaningfully, you need to inspect the actual query (or at minimum, the operation name most clients send) inside the request body, and respond differently depending on what was actually asked for — which is a body-matching problem, not a routing problem.

What actually still applies

The good news: most of what makes a REST mock useful still applies here, just applied to the body instead of the path:

• Matching on the operation being requested — a query named GetUserProfile should get a different mock response than one named CreateOrder, the same way different REST paths would. Conditional matching on the body (checking a field like operationName, or a substring of the query text) gets you this without needing a dedicated GraphQL-aware tool.
• Simulating a partial failure — GraphQL's error model allows a response to include both data and errors simultaneously (a query for three fields where one resolver failed can return the other two successfully, with an errors array explaining the third). A mock that only ever returns clean success or a fully-failed response misses this middle case entirely, and a frontend that's never seen a partial-failure GraphQL response is a frontend that hasn't actually been tested against GraphQL's real error model.
• Mutations still benefit from statefulness — a createUser mutation followed by a query that's supposed to reflect the newly created user needs the same create-then-read behavior a REST stateful mock provides; the transport being GraphQL doesn't remove the need for it.

The practical takeaway

GraphQL changes where the logic that decides "what should this specific request get back" has to live — from the URL router to something that reads the request body — but it doesn't remove the need for a mock to have that logic at all. If your mocking approach for GraphQL is "return the same canned response for every request to /graphql," you've built something that will pass a trivial smoke test and tell you nothing real about how your client handles the actual variety of queries, partial failures, and mutation-then-query flows it needs to survive in production.