N+1-problemet oppstår når en felt-resolver kjører én gang per parent-element og hver kjøring sender sin egen databasespørring. Å hente en liste med N innlegg og deretter forfatteren til hvert innlegg utløser 1 spørring for innleggene + N spørringer for forfatterne — N+1 rundturer som knuser ytelsen under last.
Resolvers kjører per felt, per element. utføres separat for hvert innlegg i listen, og ingen av dem vet om de andre, så hver enkelt gjør sin egen .
Post.authorfindById// DÅRLIG: ett DB-kall per innlegg -> N+1
const resolvers = {
Post: {
author: (post, _a, ctx) => ctx.db.users.findById(post.authorId),
},
};
DataLoader utsetter individuelle .load(id)-kall som gjøres i samme tick, og gir deretter de innsamlede nøklene til én batch-funksjon som henter dem alle i én enkelt spørring. Den cacher også etter nøkkel innenfor forespørselen, så gjentatte id-er er gratis.
import DataLoader from "dataloader";
// opprett ÉN loader per forespørsel (legg den på context så cachingen er request-scoped)
const userLoader = new DataLoader(async (ids) => {
// ids kommer som [1, 2, 3, ...] -> én enkelt batchet spørring
const users = await db.users.findByIds(ids);
// MÅ returnere verdier i SAMME REKKEFØLGE som ids
return ids.map((id) => users.find((u) => u.id === id));
});
const resolvers = {
Post: {
author: (post, _a, ctx) => ctx.userLoader.load(post.authorId), // batchet
},
};
// Nå kollapser N forfatter-resolvers til 1 spørring: totalt 2 spørringer, ikke N+1.
To regler: opprett loaders per forespørsel (ikke globalt — da lekker du utdaterte data mellom brukere), og batch-funksjonen må returnere resultater i nøyaktig nøkkelrekkefølge.
N+1 er den enkeltvis vanligste ytelsesfellen i GraphQL og et nesten garantert intervjuspørsmål. Å vise at du griper til DataLoader — og vet hvorfor den må være request-scoped og bevare rekkefølgen — signaliserer reell produksjonserfaring.
Et bibliotek av IT-intervjuspørsmål med detaljerte svar — fra Junior til Senior.
Doner