The N+1 problem happens when a field resolver runs once per parent item and each run issues its own database query. Fetching a list of N posts and then each post's author fires 1 query for the posts + N queries for the authors — N+1 round trips that crush performance under load.
Resolvers run per field, per item. executes separately for every post in the list, and none of them know about the others, so each does its own .
Post.authorfindById// BAD: one DB call per post -> N+1
const resolvers = {
Post: {
author: (post, _a, ctx) => ctx.db.users.findById(post.authorId),
},
};
DataLoader defers individual .load(id) calls made in the same tick, then hands the collected keys to one batch function that fetches them all in a single query. It also caches by key within the request, so repeated ids are free.
import DataLoader from "dataloader";
// create ONE loader per request (put it on context so caching is request-scoped)
const userLoader = new DataLoader(async (ids) => {
// ids arrives as [1, 2, 3, ...] -> a single batched query
const users = await db.users.findByIds(ids);
// MUST return values in the SAME ORDER as ids
return ids.map((id) => users.find((u) => u.id === id));
});
const resolvers = {
Post: {
author: (post, _a, ctx) => ctx.userLoader.load(post.authorId), // batched
},
};
// Now N author resolvers collapse into 1 query: total 2 queries, not N+1.
Two rules: create loaders per request (not globally — you'd leak stale data between users), and the batch function must return results in the exact key order.
N+1 is the single most common GraphQL performance trap and a near-guaranteed interview question. Showing you reach for DataLoader — and know why it must be request-scoped and order-preserving — signals real production experience.
A library of IT interview questions with detailed answers — from Junior to Senior.
Donate