N+1 সমস্যা তখন ঘটে যখন একটি field resolver প্রতিটি parent item-এর জন্য একবার করে চলে এবং প্রতিবার নিজের আলাদা database query চালায়। N-টি post-এর একটি list এনে তারপর প্রতিটি post-এর author আনতে গেলে post-এর জন্য ১টি query + author-দের জন্য N-টি query চলে — N+1টি round trip, যা load-এর নিচে performance ধ্বংস করে দেয়।
Resolver-গুলো প্রতি 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) কলগুলোকে বিলম্বিত করে, তারপর সংগৃহীত key-গুলো একটি batch function-কে দেয় যা সবগুলো একটি query-তে fetch করে। এটি request-এর মধ্যে key দিয়ে cache-ও করে, তাই পুনরাবৃত্ত id গুলো বিনামূল্যে।
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.
দুটি নিয়ম: loader-গুলো প্রতি request-এ তৈরি করুন (globally নয় — তাতে user-দের মধ্যে বাসি data ফাঁস হবে), এবং batch function-কে অবশ্যই হুবহু key-এর ক্রমে ফলাফল ফেরত দিতে হবে।
N+1 হলো সবচেয়ে সাধারণ GraphQL performance ফাঁদ এবং প্রায় নিশ্চিত একটি interview প্রশ্ন। আপনি যে DataLoader-এর দিকে হাত বাড়ান — এবং কেন এটিকে request-scoped ও order-preserving হতে হয় তা জানেন — তা বাস্তব production অভিজ্ঞতার ইঙ্গিত দেয়।
বিস্তারিত উত্তরসহ IT ইন্টারভিউ প্রশ্নের একটি লাইব্রেরি — জুনিয়র থেকে সিনিয়র পর্যন্ত।
দান করুন