What is the difference between over-fetching and under-fetching, and how does GraphQL address them?
Understand over-fetching and under-fetching, why REST causes them, and how a GraphQL selection set returns exactly the data a client needs in one request.
Expected Interview Answer
Over-fetching is when an API returns more data than the client needs; under-fetching is when a single request returns too little, forcing the client to make additional round trips. GraphQL addresses both by letting the client specify exactly which fields it wants in one request.
Traditional REST endpoints return a fixed shape, so a screen needing only a user's name still downloads the whole user object (over-fetching), and a screen needing a user plus their posts and followers must hit several endpoints (under-fetching, also called the N+1 or waterfall problem). Because a GraphQL query is a declarative selection set, the client asks for precisely the fields it needs, and can traverse related data in the same request. The server resolves exactly that shape, eliminating wasted payload and extra round trips.
- Smaller payloads — only requested fields are returned
- Fewer network round trips by fetching related data together
- Clients evolve their data needs without new endpoints
- Better performance on slow mobile networks
- A single, self-documenting request describes exactly what the UI uses
AI Mentor Explanation
Over-fetching is asking for the full career records of every player when you only want today's score; under-fetching is the scoreboard showing runs but making you check a separate board for wickets and overs. GraphQL is a smart scoreboard where you name exactly the stats you want — runs, wickets, overs — and it shows just those in one glance.
Step-by-Step Explanation
Step 1
Spot over-fetching
Notice a REST endpoint returning fields the current screen never uses, wasting bandwidth.
Step 2
Spot under-fetching
Notice the same screen firing several requests to assemble one view's data.
Step 3
Write a precise selection set
In GraphQL, list only the fields the UI renders inside the query.
Step 4
Traverse relationships inline
Nest related data (user -> posts -> comments) so it all resolves in one request.
Step 5
Let resolvers fetch each field
The server runs a resolver per requested field, returning exactly the requested shape.
What Interviewer Expects
- Clear definitions of over-fetching and under-fetching
- Understanding that REST's fixed shapes cause both
- How a GraphQL selection set returns only requested fields
- How nested queries avoid multiple round trips
- Awareness that resolvers can still cause N+1 without batching
Common Mistakes
- Swapping the definitions of over- and under-fetching
- Claiming GraphQL automatically prevents backend N+1 database queries
- Ignoring that clients can still request too much data
- Thinking GraphQL replaces caching or batching (DataLoader)
- Assuming one GraphQL request is always faster than a few REST calls
Best Answer (HR Friendly)
“Over-fetching means an API sends more data than you need, and under-fetching means it sends too little so you have to ask again. GraphQL fixes both by letting the app request exactly the fields it wants in a single call, which saves data and speeds up the screen.”
Code Example
query DashboardData {
user(id: "42") {
name
posts(last: 3) {
title
comments {
text
}
}
}
}// Under-fetching in REST needs multiple round trips:
GET /users/42 // over-fetches full user object
GET /users/42/posts // then fetch posts
GET /posts/101/comments // then comments per post (N+1)Follow-up Questions
- How does the N+1 problem appear inside GraphQL resolvers?
- What is DataLoader and how does it batch resolver calls?
- Can a GraphQL client still over-fetch, and how do you prevent it?
- How do query cost analysis and depth limiting help here?
- When might a REST endpoint still be the better choice?
MCQ Practice
1. Under-fetching is best described as?
Under-fetching means one response is insufficient, forcing extra round trips to assemble the needed data.
2. How does GraphQL primarily reduce over-fetching?
A GraphQL selection set returns only the fields the client explicitly requests, so nothing extra is sent.
3. Which issue can persist on the SERVER even when the client query is precise?
Field resolvers can each hit the database, causing N+1 queries unless batched with a tool like DataLoader.
Flash Cards
Define over-fetching. — The API returns more data than the client actually needs.
Define under-fetching. — One request returns too little, forcing extra round trips to gather the data.
How does GraphQL solve both? — Clients request exactly the fields they need, including nested relations, in a single query.
Does GraphQL fix backend N+1 automatically? — No — resolvers can still cause N+1; batch them with DataLoader.