GraphQL vs REST: How Do They Fetch Data From Databases Differently?
Compare how GraphQL and REST fetch data from databases, including the N+1 resolver risk and when each approach wins.
Expected Interview Answer
REST exposes fixed, resource-shaped endpoints that each return a predetermined set of columns and joins decided by the server, while GraphQL exposes a single endpoint where the client specifies exactly which fields and nested relations it needs, and the server resolvers translate that request into the underlying database queries.
With REST, if a screen needs a user plus their last five orders, the client typically calls two endpoints or relies on a bespoke aggregate endpoint the backend team pre-built, and it receives every field the endpoint defines whether it needs them or not. With GraphQL, the client sends one query naming the exact fields (user.name, orders.total) and nested relations it wants, and each field resolves independently, often triggering its own database call or join under the hood. This gives GraphQL flexibility and avoids over-fetching, but it also makes it easy to accidentally trigger the N+1 query problem across nested resolvers unless batching (DataLoader-style) is used, whereas REST endpoints usually have their database access pattern fixed and tuned once by the backend team.
- REST: predictable, cacheable, database access pattern fixed per endpoint
- GraphQL: client controls exact fields, reducing over-fetching
- GraphQL resolvers can each hit the database independently
- Both still ultimately execute normal SQL/NoSQL queries underneath
AI Mentor Explanation
A REST API is like a stadium scoreboard operator who only ever displays the same fixed set of fields — score, overs, wickets — no matter who is watching, because that layout was decided once. A GraphQL API is like handing the operator a custom request form where you tick exactly the fields you want shown, say strike rate and partnership runs but not extras, and the operator pulls only those from the scoring database. Both read from the same underlying scorebook data; only the shape of what is returned differs.
Step-by-Step Explanation
Step 1
Client sends a request
REST calls a specific URL/verb; GraphQL sends one query naming the exact fields and nested relations needed.
Step 2
Server routes the request
REST maps the URL to a controller with a fixed query; GraphQL parses the query and dispatches each field to its resolver.
Step 3
Resolvers hit the database
REST runs its predetermined joins/queries once; GraphQL resolvers may each issue separate database calls, risking N+1 without batching.
Step 4
Response is shaped and returned
REST returns the endpoint's full fixed payload; GraphQL assembles only the requested fields into one response.
What Interviewer Expects
- Clear articulation of fixed-shape endpoints vs client-specified field selection
- Awareness that both still execute normal database queries underneath
- Mention of over-fetching/under-fetching and the N+1 resolver risk
- Ability to discuss when REST caching wins vs when GraphQL flexibility wins
Common Mistakes
- Claiming GraphQL is a database technology rather than a query layer over one
- Ignoring the N+1 query risk in nested GraphQL resolvers
- Assuming REST cannot ever return partial or aggregated data
- Failing to mention HTTP caching as a REST advantage GraphQL sacrifices
Best Answer (HR Friendly)
“REST gives you fixed endpoints that always return the same shaped data, while GraphQL lets the client ask for exactly the fields it needs in one request. Both still run normal database queries behind the scenes, but GraphQL trades REST's simple caching for more flexible, precisely-shaped responses, at the cost of needing careful resolver design to avoid firing too many database queries.”
Code Example
-- GraphQL query: { user(id: 1) { name orders { total } } }
-- resolves into separate underlying SQL calls per field:
SELECT name FROM Users WHERE id = 1;
SELECT total FROM Orders WHERE user_id = 1;
-- A naive resolver run per-order (N+1) instead looks like:
SELECT total FROM Orders WHERE user_id = 1;
-- then, for each order row returned, an extra query such as:
SELECT * FROM OrderItems WHERE order_id = 501;
-- repeated once per order -- this is the classic N+1 problem
-- that DataLoader-style batching is used to avoid.Follow-up Questions
- How would you solve the N+1 query problem in a GraphQL resolver?
- How does HTTP caching differ between a REST endpoint and a GraphQL endpoint?
- When would you still choose REST over GraphQL for a new service?
- How does GraphQL handle versioning compared to REST?
MCQ Practice
1. What is the main data-fetching difference between REST and GraphQL?
GraphQL clients declare exactly which fields and nested relations they want, while REST endpoints return a predetermined fixed response shape.
2. What common performance risk arises from nested GraphQL resolvers?
Naive nested resolvers can issue one database query per parent row, causing an N+1 explosion of queries without batching.
3. Which is typically easier to cache at the HTTP layer?
REST resource URLs map naturally to HTTP caching, while GraphQL's single POST endpoint with variable queries is harder to cache generically.
Flash Cards
REST data fetching? — Fixed, server-defined response shape per endpoint, decided in advance.
GraphQL data fetching? — Client specifies exact fields/relations in one query; resolvers fetch only what was asked.
What is the N+1 problem? — A resolver issuing one extra database query per row in a parent result set instead of batching.
Do GraphQL and REST both use databases the same way? — Yes, both ultimately run normal SQL/NoSQL queries; the difference is in the API contract shaping the response.