Over-fetching and under-fetching problems in GraphQL - Deep Dive

Overview - Over-fetching and under-fetching problems

What is it?

Over-fetching and under-fetching are common problems when getting data from a server. Over-fetching means you get more data than you need, which wastes time and resources. Under-fetching means you get too little data, so you have to ask again to get more. These problems happen when the way you ask for data is not flexible enough.

Why it matters

Without solving these problems, apps can be slow or use too much internet data. Imagine a phone app that downloads a whole book when you only want one page (over-fetching), or only a few words and then has to ask for the rest repeatedly (under-fetching). This makes the app frustrating and inefficient. Fixing these problems makes apps faster and saves battery and data.

Where it fits

Before learning this, you should understand how APIs and data fetching work in general. After this, you can learn about GraphQL, which is a tool designed to solve these problems by letting you ask exactly for the data you want.

Mental Model

Core Idea

Over-fetching and under-fetching happen when the data request is not precise enough, causing either too much or too little data to be sent.

Think of it like...

It's like ordering food at a restaurant: over-fetching is like getting a whole buffet when you only wanted a sandwich, and under-fetching is like getting just a slice of bread and having to ask for more pieces repeatedly.

┌───────────────┐       ┌───────────────┐
│ Client asks   │──────▶│ Server sends  │
│ for data     │       │ data          │
└───────────────┘       └───────────────┘
       ▲                      ▲
       │                      │
       │                      │
  Over-fetching:           Under-fetching:
  Too much data sent       Too little data sent
  Wastes time and data     Requires multiple requests

Build-Up - 7 Steps

1

Foundation

What is data fetching

Concept: Understanding the basic idea of getting data from a server.

When you use an app or website, it often needs information stored somewhere else, called a server. Data fetching is the process where your app asks the server for this information and the server sends it back.

Result

You get the data you need to show or use in your app.

Understanding data fetching is the first step to seeing why getting the right amount of data matters.

2

Foundation

Fixed data requests and their limits

Concept: How traditional APIs send fixed sets of data regardless of what the client really needs.

Many older APIs send a fixed amount of data for each request. For example, asking for a user might always send their name, email, address, and phone number, even if the app only needs the name.

Result

You often get more data than needed, which can slow down the app.

Knowing that fixed data requests cause inefficiency helps explain why over-fetching happens.

3

Intermediate

Understanding over-fetching problem

🤔Before reading on: do you think getting extra data you don't use is harmless or wasteful? Commit to your answer.

Concept: Over-fetching means receiving more data than the app actually needs.

When the server sends all data fields even if the app uses only some, it wastes bandwidth and processing time. For example, downloading full user profiles when only usernames are shown.

Result

Slower app performance and higher data costs.

Understanding over-fetching shows why precise data requests improve speed and efficiency.

4

Intermediate

Understanding under-fetching problem

🤔Before reading on: do you think getting too little data means fewer requests or more requests? Commit to your answer.

Concept: Under-fetching means getting too little data, forcing extra requests to get what is missing.

If the server sends only part of the needed data, the app must ask again for more. For example, getting only user IDs but needing to request each user's details separately.

Result

More network requests, slower loading, and complex code.

Knowing under-fetching explains why flexible queries that get all needed data at once are better.

5

Intermediate

How GraphQL solves these problems

Concept: GraphQL lets clients specify exactly what data they want, avoiding over- and under-fetching.

With GraphQL, you write a query that lists only the fields you need. The server sends exactly that data. This means no extra data is sent, and you get everything you need in one request.

Result

Efficient data transfer and simpler client code.

Understanding GraphQL's precise queries reveals how it fixes common data fetching issues.

6

Advanced

Trade-offs in flexible data fetching

🤔Before reading on: do you think flexible queries always improve performance or can they sometimes add complexity? Commit to your answer.

Concept: Flexible data fetching improves efficiency but can add complexity in query design and server processing.

While GraphQL solves over- and under-fetching, it requires careful query design to avoid very complex queries that can slow down the server. Also, caching and security become more challenging.

Result

Better client efficiency but requires skilled backend design.

Knowing the trade-offs helps balance flexibility with performance and security.

7

Expert

Unexpected pitfalls of over- and under-fetching fixes

🤔Before reading on: do you think solving over-fetching always reduces server load? Commit to your answer.

Concept: Fixing these problems can introduce new issues like increased server computation or complex caching strategies.

GraphQL queries can be very specific but expensive to compute, causing server strain. Also, caching responses is harder because queries vary widely. These challenges require advanced techniques like query complexity analysis and persisted queries.

Result

Improved client experience but more complex backend infrastructure.

Understanding these hidden costs prevents surprises in production and guides better system design.

Under the Hood

Traditional APIs send fixed data shaped by the server, often as REST endpoints returning full objects. GraphQL uses a query language where the client specifies fields, and the server resolves these fields dynamically, fetching only requested data. This dynamic resolution involves parsing the query, validating it, and executing resolvers for each field, which can be nested and complex.

Why designed this way?

GraphQL was designed to solve inefficiencies in REST APIs where clients often received too much or too little data. The goal was to give clients control over data shape to improve performance and developer experience. Alternatives like multiple REST endpoints or custom parameters were too rigid or complex, so GraphQL's flexible query language was chosen.

Client Query ──▶ GraphQL Server ──▶ Resolver Functions ──▶ Data Sources
       │                 │                     │
       │                 │                     └─▶ Database, APIs, Services
       │                 └─▶ Query Parsing & Validation
       └─▶ Response with exactly requested fields

Myth Busters - 3 Common Misconceptions

Quick: Does over-fetching mean the server sends useless data or the client ignores data? Commit yes or no.

Common Belief: Over-fetching means the client just ignores extra data sent by the server.

Reality: Over-fetching means the server sends more data than needed, which wastes bandwidth and processing, not just ignored data.

Why it matters: Ignoring extra data still costs time and network resources, slowing down apps and increasing costs.

Quick: Does under-fetching mean fewer requests or more requests? Commit your answer.

Common Belief: Under-fetching means fewer requests because less data is sent.

Reality: Under-fetching causes more requests because the client must ask multiple times to get all needed data.

Why it matters: More requests increase latency and complexity, making apps slower and harder to maintain.

Quick: Does GraphQL always eliminate all performance problems? Commit yes or no.

Common Belief: GraphQL always fixes over-fetching and under-fetching perfectly with no downsides.

Reality: GraphQL reduces these problems but can introduce server load issues and caching challenges if not managed well.

Why it matters: Assuming GraphQL is a silver bullet can lead to unexpected performance bottlenecks in production.

Expert Zone

1

GraphQL queries can be deeply nested, causing complex data fetching that may negate performance gains if not limited.

2

Caching GraphQL responses is harder than REST because queries vary widely; techniques like persisted queries help but add complexity.

3

Over-fetching can sometimes be intentional to reduce the number of requests, trading bandwidth for latency.

When NOT to use

Avoid GraphQL when your data needs are simple and fixed, or when server resources are limited and cannot handle complex query resolution. REST or simpler APIs may be better for static or cache-heavy scenarios.

Production Patterns

In real systems, GraphQL is often combined with query complexity limits, persisted queries, and batching to control performance. Teams use schema stitching or federation to manage large APIs, and monitor query costs to prevent abuse.

Connections

REST APIs

GraphQL builds on and improves REST by allowing flexible data queries instead of fixed endpoints.

Understanding REST helps appreciate why GraphQL was created to solve over- and under-fetching.

Caching strategies

Caching in GraphQL is more complex than in REST due to variable queries, requiring new approaches.

Knowing caching challenges helps design efficient GraphQL systems that avoid performance pitfalls.

Supply chain management

Both involve optimizing requests and deliveries to avoid excess or shortage.

Understanding over- and under-fetching is like managing inventory: too much stock wastes space, too little causes delays.

Common Pitfalls

#1 Requesting full data objects when only a few fields are needed.

Wrong approach:

query { user { id name email address phone } } // when only name is needed

Correct approach:

query { user { name } }

Root cause:

Not understanding that GraphQL lets you specify exactly which fields you want.

#2 Splitting data requests into many small queries causing many network calls.

Wrong approach:

query { userIds } then for each id: query { user(id: $id) { name } }

Correct approach:

query { users { id name } }

Root cause:

Not realizing you can request multiple items in one query to reduce requests.

#3 Assuming GraphQL queries are always cheap and ignoring query complexity.

Wrong approach:

Allowing clients to send deeply nested queries without limits.

Correct approach:

Implementing query depth limits and complexity analysis on the server.

Root cause:

Overlooking that flexible queries can cause heavy server load if unchecked.

Key Takeaways

Over-fetching and under-fetching happen when data requests are not precise, causing inefficiency.

Over-fetching wastes bandwidth and slows apps by sending extra unused data.

Under-fetching causes multiple requests and delays by sending too little data at once.

GraphQL solves these problems by letting clients specify exactly what data they want.

However, flexible queries require careful server design to avoid new performance issues.