N+1 مسئلہ اس وقت ہوتا ہے جب کوئی field resolver ہر parent item کے لیے ایک بار چلتا ہے اور ہر بار اپنی الگ database query چلاتا ہے۔ N posts کی list حاصل کرنا اور پھر ہر post کا author لانا posts کے لیے 1 query + authors کے لیے N queries چلاتا ہے — N+1 round trips جو بوجھ کے تحت performance کو تباہ کر دیتے ہیں۔
Resolvers ہر field، ہر item کے لیے چلتے ہیں۔ list کے ہر post کے لیے الگ سے چلتا ہے، اور ان میں سے کسی کو دوسروں کا علم نہیں ہوتا، اس لیے ہر ایک اپنا کرتا ہے۔
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 کو مؤخر کرتا ہے، پھر جمع شدہ 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 کے درمیان stale data leak کر دیں گے)، اور batch function کو results بالکل key کی ترتیب میں واپس کرنے چاہئیں۔
N+1 GraphQL کا سب سے عام performance جال ہے اور تقریباً یقینی interview سوال ہے۔ یہ دکھانا کہ آپ DataLoader کی طرف بڑھتے ہیں — اور جانتے ہیں کہ یہ کیوں request-scoped اور order-preserving ہونا چاہیے — حقیقی production تجربے کی نشاندہی کرتا ہے۔
تفصیلی جوابات کے ساتھ IT انٹرویو سوالات کی ایک لائبریری — جونیئر سے سینئر تک۔
عطیہ دیں