N+1 problem ત્યારે થાય છે જ્યારે કોઈ field resolver દરેક parent item દીઠ એક વાર ચાલે અને દરેક વખતે તેની પોતાની database query issue કરે. N posts ની list લાવવી અને પછી દરેક post નો author લાવવો posts માટે 1 query + authors માટે N queries fire કરે છે — N+1 round trips જે load હેઠળ performance ને કચડી નાખે છે.
Resolvers per field, per item ચાલે છે. list ના દરેક post માટે અલગથી execute થાય છે, અને તેમાંથી કોઈને બીજા વિશે ખબર નથી, તેથી દરેક પોતાનું કરે છે.
Post.authorfindById// BAD: one DB call per post -> N+1
const resolvers = {
Post: {
author: (post, _a, ctx) => ctx.db.users.findById(post.authorId),
},
};
DataLoader એક જ tick માં કરાયેલા વ્યક્તિગત .load(id) calls ને defer કરે છે, પછી એકઠી કરેલી keys એક batch function ને સોંપે છે જે તે બધીને એક જ query માં લાવે છે. તે request ની અંદર key પ્રમાણે cache પણ કરે છે, તેથી પુનરાવર્તિત ids મફત છે.
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.
બે નિયમો: loaders per request બનાવો (globally નહીં — નહીં તો તમે users વચ્ચે stale data leak કરશો), અને batch function એ results બરાબર key ના ક્રમમાં પરત કરવા જ જોઈએ.
N+1 એ સૌથી સામાન્ય GraphQL performance જાળ છે અને લગભગ ખાતરીપૂર્વકનો interview પ્રશ્ન છે. તમે DataLoader તરફ વળો છો એ બતાવવું — અને શા માટે તે request-scoped અને order-preserving હોવું જોઈએ એ જાણવું — વાસ્તવિક production અનુભવ દર્શાવે છે.
વિગતવાર જવાબો સાથે IT ઇન્ટરવ્યૂ પ્રશ્નોની લાઇબ્રેરી — જુનિયરથી સિનિયર સુધી.
દાન કરો