API design
GraphQL vs REST: interview questions and practical design
GraphQL and REST make different trade-offs in contract shape, client flexibility, caching, authorisation, and operational control; neither is a universal replacement for the other.
Written and reviewed by Sahil Srivastav
What it actually is
GraphQL and REST make different trade-offs in contract shape, client flexibility, caching, authorisation, and operational control; neither is a universal replacement for the other.
A decision should follow access patterns and ownership. Flexible field selection can reduce over-fetching while making cost, caching, and resolver behaviour harder to bound.
The useful interview answer is precise about the boundary: GraphQL lets a client request a graph-shaped selection through one endpoint; REST exposes resource representations and operations. GraphQL needs depth, complexity, and resolver controls to prevent expensive queries.
Why it matters in production
A decision should follow access patterns and ownership. Flexible field selection can reduce over-fetching while making cost, caching, and resolver behaviour harder to bound.
REST’s resource and HTTP semantics work well with generic tooling and independent cache layers, while GraphQL centralises a typed query contract for varied clients.
How it works
Query shape and control
GraphQL lets a client request a graph-shaped selection through one endpoint; REST exposes resource representations and operations. GraphQL needs depth, complexity, and resolver controls to prevent expensive queries.
Caching and transport
REST can use HTTP caching naturally with resource URLs and validators. GraphQL often needs persisted queries, response caching, or field-aware strategies because query strings vary.
Errors and partial data
GraphQL can return data plus an errors array, requiring clients to handle partial results. REST commonly maps one operation outcome to a status and body; both need a stable domain error contract.
Implementing it
Map three client screens to resource endpoints and to a GraphQL schema, then compare ownership and caching.
Add a query complexity limit and resolver batching to a GraphQL design.
Test authorisation at field and object boundaries, not only at the top-level query.
Interview questions and how to answer them
When is GraphQL a good fit?
When clients have varied graph-shaped data needs and a shared typed schema can coordinate that flexibility. It is less attractive when simple resource caching and strict cost control dominate.
How do you prevent GraphQL abuse?
Use depth and complexity limits, persisted queries or allow-lists where appropriate, resolver batching, timeouts, and per-client budgets.
How does REST handle over-fetching?
Use focused resources, field selection, embedded representations, or endpoint changes based on measured client needs; it does not require one giant representation.
Answers that lose the round
- Choosing GraphQL because it has one endpoint without discussing query cost.
- Assuming REST forbids flexible representations or GraphQL solves N+1 automatically.
- Applying authorisation only to the root resolver or controller.
- Ignoring versioning and deprecation for a GraphQL schema.
FAQ
Is GraphQL faster than REST?
Not inherently. It can reduce round trips or payload waste, but resolver fan-out and query planning can cost more. Measure the workload.
Can GraphQL use HTTP caching?
Yes, but varying query documents and variables make generic caching harder. Persisted queries and stable response keys help.
Should internal APIs use GraphQL?
Choose from consumer needs, ownership, and operational controls. Internal status does not remove the need for cost and authorisation boundaries.