Q20 of 20 · GraphQL
From a testing and quality standpoint, when might REST be a better choice than GraphQL?
Short answer
Short answer: When you want HTTP caching and CDN behaviour for free, simple per-endpoint authorisation, predictable fixed responses, or a smaller security/performance surface. GraphQL's flexibility adds N+1, depth/complexity, nested-authz, and 200-on-error concerns that REST mostly avoids.
Detail
A balanced senior answer — interviewers want to know you can critique the tech you test, not just operate it.
REST tends to be simpler to test and operate when:
- Caching matters: REST's distinct URLs and proper status codes work with HTTP caching and CDNs out of the box; GraphQL's single POST endpoint needs more deliberate caching (persisted queries, etc.).
- Authorisation is simple: per-endpoint authz is easier to reason about and test than per-field authz across an arbitrary graph.
- Responses are fixed and predictable: if clients all want the same shape, GraphQL's flexibility is overhead, and fixed responses are trivially cacheable and testable.
- You want a smaller surface: GraphQL adds N+1, query depth/complexity DoS, introspection exposure, and the 200-on-error subtlety — each a class of bug REST mostly sidesteps.
GraphQL earns its complexity when clients genuinely need flexible, varied data shapes (e.g. many different frontends, mobile bandwidth constraints, deeply related data). The quality lens: every bit of that flexibility is also a test surface, so the choice should be driven by real client needs, not novelty.
// WHAT INTERVIEWERS LOOK FOR
// COMMON PITFALL
// Related questions