Batching GraphQL resolvers with DataLoader

The portfolio holdings endpoint returned a list of positions. Each position included details about the underlying asset: name, type, a few regulatory identifiers. The response shape was correct. The latency was not.

On a small local dataset it felt fine. In staging, with a realistic account holding two hundred positions, it took several seconds. The query logs explained why: one query to fetch the positions, then one query per position to fetch its asset. Two hundred and one queries, sequential, for a single HTTP request.

This is the N+1 problem. It is almost invisible in local development and almost always present when a GraphQL resolver fetches a related entity by ID.

I turned on TypeORM query logging in staging and ran the endpoint against a large account. The output was immediately readable: the same SELECT against the assets table, once per position, each with a different id in the WHERE clause. Not parallel. Each one waited for the previous to complete.

The source was the asset field resolver:

assetService.findById(position.assetId)

Called once per position, with no batching and no awareness that 199 other callers were about to issue the same query with a different ID. GraphQL resolves fields concurrently within a layer, but each resolver was still making its own round-trip to the database.

DataLoader defers all calls in the same event loop tick, collects the IDs, issues one batched query, and distributes results back to each caller. The resolver went from:

return assetService.findById(position.assetId)

to:

return this.assetLoader.load(position.assetId)

The loader batches all IDs collected in the tick into a single SELECT * FROM assets WHERE id IN (...) and maps results back by ID. The resolver code barely changes. The query count drops from N+1 to 2.

The loader was scoped per request using NestJS's @Scope(Scope.REQUEST). A fresh instance per HTTP request means no cross-request caching. The scoping decision matters more than the batching in a multi-tenant system.

After fixing the asset resolver I audited the rest of the resolver tree and found the same pattern in two others. All three went out in the same PR.