Abdul Ahad | Senior Full-Stack Engineer | Last Updated: March 2026
GraphQL was billed as the ultimate solution to REST's over-fetching problem. In theory, frontend clients request exactly what they need, and nothing more. In practice, unoptimized GraphQL architectures often result in massive frontend payload bloat, redundant network requests, and the notorious N+1 query problem crushing the database.
During a recent scale-up phase for a global enterprise SaaS platform, our raw GraphQL implementation was hitting PostgreSQL 4,000 times to render a single dashboard page. Here is how we implemented Apollo Client's InMemoryCache and backend DataLoader batching to drop our P99 data fetching latency from 1.8 seconds down to 120ms.
The Problem: The N+1 Query Nightmare
In a standard REST architecture, fetching a list of users and their associated posts requires two tuned endpoints. In GraphQL, because resolvers execute independently for each field, fetching 100 users and their profile images can trigger 1 query for the users, and 100 individual queries for the profile data. This is the N+1 problem.
The Backend Fix: DataLoader Batching
Before optimizing the client, the server must be protected. We utilized dataloader, a utility provided by Facebook, to batch and cache database requests within a single GraphQL request lifecycle.
// src/loaders/userLoader.ts
import DataLoader from 'dataloader';
import { db } from '../db';
// Batch function: receives an array of IDs and returns an array of Users
const batchUsers = async (userIds: readonly number[]) => {
// 1. Fetch all users in a single SQL query
const users = await db.query(
'SELECT * FROM users WHERE id IN ($1)',
[userIds]
);
// 2. Map the results back to the original requested order
const userMap = new Map(users.rows.map(u => [u.id, u]));
return userIds.map(id => userMap.get(id) || null);
};
// Create a new DataLoader instance per request to avoid cross-request caching
export const createUserLoader = () => new DataLoader(batchUsers);
By injecting createUserLoader into the GraphQL context, those 100 individual SQL queries are grouped into a single SELECT * FROM users WHERE id IN (...) query. This optimization alone reduced database load by 98%.
The Frontend Fix: Normalized Caching with Apollo Client
Even with a fast server, network round-trips are expensive. Apollo Client's InMemoryCache is arguably the most powerful tool for React applications to reduce network requests.
When an Apollo Client receives a GraphQL response, it doesn't just store the JSON string. It normalizes the data. It splits the response into individual objects based on their __typename and id, storing them in a flat lookup table.
Implementing Cache Normalization and Fragments
If component A fetches a user's name, and component B fetches the same user's profilePicture, Apollo is smart enough to merge these fields in the cache. To ensure consistency across large codebases, we enforce the use of GraphQL Fragments.
// 1. Define the fragment alongside the UI component that uses it
export const USER_AVATAR_FRAGMENT = gql`
fragment UserAvatar on User {
id
name
profilePicture
}
`;
// 2. Compose queries using the fragment
const GET_DASHBOARD_FEED = gql`
${USER_AVATAR_FRAGMENT}
query GetDashboardFeed {
posts {
id
title
author {
...UserAvatar
}
}
}
`;
const GET_USER_PROFILE = gql`
${USER_AVATAR_FRAGMENT}
query GetUserProfile($id: ID!) {
user(id: $id) {
...UserAvatar
email
joinDate
}
}
`;
Because both queries use the exact same structural fragment, navigating from the Dashboard to a User Profile feels instantaneous. Apollo recognizes that the UserAvatar data is already cached and renders the UI immediately while fetching the remaining email and joinDate fields in the background.
The Cost of Complexity
Apollo Client is heavy. The @apollo/client package adds roughly ~40kb (minzipped) to your browser bundle. If your application consists merely of basic CRUD forms, Apollo is overkill and react-query or standard fetch with Next.js Server Actions is significantly more performant. You should only adopt Apollo Client when your application requires robust, normalized entity management shared across dozens of distinct React components.
Frequently Asked Questions
What is the main benefit of GraphQL over REST?
Unlike REST which organizes data via rigid endpoints, GraphQL allows clients to specify the exact shape and fields of the data they need. This eliminates over-fetching (downloading unneeded data) and under-fetching (requiring multiple waterfall requests to assemble a view).
What is the GraphQL N+1 Problem?
The N+1 problem occurs when a GraphQL server executes one database query to get a list of parent records (the "1"), and then executes an additional separate database query for each child record (the "N"). It is traditionally solved using batching tools like DataLoader.
How does Apollo Client's InMemoryCache improve performance?
The InMemoryCache normalizes GraphQL response data by splitting it into individual objects stored by a unique identifier (usually __typename + id). This enables components across different pages to share the exact same cached data entities, eliminating redundant network requests.