APIs
GraphQL N+1: multiple-choice review
Crux Multiple-choice synthesis across the GraphQL N+1 unit — resolver isolation, DataLoader scope, batch contracts, federation, and query-shape defences.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. Each one is a decision you make in a real review or incident — not a definition to recite, but a tradeoff to weigh when one HTTP request is quietly firing a thousand SQL queries.
Goal
Confirm you can connect resolver isolation, DataLoader batching and scope, batch-function contracts, federation, and query-shape defences — the synthesis the six lessons built toward.
Quiz
Completed
A REST controller serving the same posts-with-authors page issues one JOIN; the GraphQL server issues 51 queries. The schema has no bug. What is the structural cause?
Heads-up Both run over HTTP; transport is not the cause. The cost is resolver isolation firing one fetch per parent, with no place to write a JOIN.
Heads-up Most GraphQL servers are async and could batch — DataLoader proves it. N+1 is about resolver isolation, not threading.
Heads-up The spec defines no caching, but that is unrelated. The 51 queries come from per-field resolver execution, not a missing cache.
Quiz
Completed
Why does DataLoader batch on the event-loop tick boundary rather than a fixed 5 ms timer, and what does that buy you?
Heads-up Node supports setTimeout and setImmediate; DataLoader could use them. It chooses the microtask boundary specifically to avoid added latency.
Heads-up Memory is set by batch size, not dispatch timing. The reason is latency: the tick boundary fires the instant the level's loads are all queued.
Heads-up Dispatch timing does not change resolver ordering. The benefit is firing at the earliest complete moment with no wait.
Quiz
Completed
A refactor moved one DataLoader from the Apollo context factory into module scope. DB call rate is 6× normal at unchanged HTTP rate, and one tenant intermittently sees another tenant's rows. Why?
Heads-up Memory size is not the failure here. A shared instance leaks cached rows across tenants and serves stale data — the data-correctness bug is the symptom.
Heads-up Module scope does not disable batching within a tick; it shares the cache across requests. The leak and staleness are the defects, not lost batching.
Heads-up Disabling cache hides staleness but the instance is still shared across tenants. The real fix is per-request instantiation in the context factory.
Quiz
Completed
A batchLoadFn runs SELECT ... WHERE id = ANY($1) and returns the rows in the order Postgres gave them. Intermittently, posts show the wrong author. What is the rule it broke?
Heads-up The SQL is valid; ordering in SQL is not the contract. DataLoader maps the i-th returned value to the i-th key, so you reorder in the batch function with a Map.
Heads-up DataLoader trusts the array's positions and does not validate ordering. The corruption is silent — exactly why the Map-by-key pattern is mandatory.
Heads-up This is an ordering bug, not a caching bug. Disabling cache changes nothing; you must align returned values to input-key positions.
Quiz
Completed
An Apollo Federation supergraph routes a query referencing 50 users across two subgraphs. What does the router handle, and what does the users subgraph still owe?
Heads-up Subgraphs do not share databases; the router talks HTTP, not SQL. It batches representations, but each subgraph owns its own DB batching.
Heads-up Federation batches at the network level only. Intra-subgraph N+1 in __resolveReference is still your responsibility — add DataLoader.
Heads-up It sends one _entities call with all 50 representations. The remaining problem is the 50 per-representation DB lookups inside the subgraph.
Quiz
Completed
DataLoader is live and the page is fast. An attacker sends one document with 1000 root aliases (q1: user(id:1)…q1000: user(id:1000)). DB trips collapse to one batch, yet the server still struggles. Why, and what stops it?
Heads-up DataLoader can split with maxBatchSize; the database trip is not the bottleneck. The cost is 1000 resolver executions, which alias caps stop at validation.
Heads-up Introspection only aids reconnaissance; the schema can be reconstructed from errors. Alias bombs are a query-shape attack stopped by alias and batch caps.
Heads-up Alias bombs amplify within a single request, so per-request rate limits are exactly what they bypass. You need an alias cap and complexity scoring.
Recap
The unit’s through-line is one pipeline: resolver isolation creates N+1, DataLoader collapses the DB trips at the tick boundary but only with per-request scope and a correct same-order batch contract, federation hands you the network batch while you still owe the DB batch in __resolveReference, and query-shape defences (depth, multiplicative complexity, persisted/trusted documents, alias and batch caps) stop the attacks DataLoader cannot touch. DataLoader fixes how many DB trips a query makes; the defence layers govern what query shapes are even allowed to run.