N+1 problem ਉਦੋਂ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਇੱਕ field resolver ਹਰ parent item ਲਈ ਇੱਕ ਵਾਰ ਚੱਲਦਾ ਹੈ ਅਤੇ ਹਰ ਵਾਰੀ ਆਪਣੀ ਖੁਦ ਦੀ database query ਭੇਜਦੀ ਹੈ। N posts ਦੀ list fetch ਕਰਨਾ ਅਤੇ ਫਿਰ ਹਰ post ਦਾ author posts ਲਈ 1 query + authors ਲਈ N query 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 ਵਿੱਚ ਕੀਤੇ ਗਏ individual .load(id) calls ਨੂੰ defer ਕਰਦਾ ਹੈ, ਫਿਰ ਇਕੱਠੀਆਂ keys ਨੂੰ ਇੱਕ 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.
ਦੋ ਨਿਯਮ: loaders per request ਬਣਾਓ (globally ਨਹੀਂ — ਤੁਸੀਂ users ਵਿਚਕਾਰ stale data leak ਕਰ ਦਿਓਗੇ), ਅਤੇ batch function ਨੂੰ results ਬਿਲਕੁਲ key ਦੇ ਕ੍ਰਮ ਵਿੱਚ ਵਾਪਸ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ।
N+1 ਸਭ ਤੋਂ ਆਮ GraphQL performance ਜਾਲ ਹੈ ਅਤੇ ਇੱਕ ਲਗਭਗ ਪੱਕਾ interview ਸਵਾਲ ਹੈ। ਇਹ ਦਿਖਾਉਣਾ ਕਿ ਤੁਸੀਂ DataLoader ਵੱਲ ਹੱਥ ਵਧਾਉਂਦੇ ਹੋ — ਅਤੇ ਕਿਉਂ ਇਹ request-scoped ਅਤੇ order-preserving ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਇਹ ਜਾਣਦੇ ਹੋ — ਅਸਲ production ਅਨੁਭਵ ਦਾ ਸੰਕੇਤ ਦਿੰਦਾ ਹੈ।
ਵਿਸਤ੍ਰਿਤ ਜਵਾਬਾਂ ਨਾਲ IT ਇੰਟਰਵਿਊ ਸਵਾਲਾਂ ਦੀ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ — ਜੂਨੀਅਰ ਤੋਂ ਸੀਨੀਅਰ ਤੱਕ।
ਦਾਨ ਕਰੋ