N+1 समस्या तब होती है जब कोई 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 प्रति field, प्रति 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 को प्रति request बनाएँ (globally नहीं — वरना आप users के बीच बासी data leak कर देंगे), और batch function को परिणाम ठीक उसी key क्रम में लौटाने चाहिए।
N+1 सबसे आम GraphQL performance जाल है और लगभग निश्चित रूप से पूछा जाने वाला interview प्रश्न है। यह दिखाना कि आप DataLoader की ओर जाते हैं — और जानते हैं कि यह क्यों request-scoped और order-preserving होना चाहिए — असल production अनुभव का संकेत देता है।
विस्तृत उत्तरों के साथ IT इंटरव्यू प्रश्नों की एक लाइब्रेरी — जूनियर से सीनियर तक।
दान करें