Count the Resolver, Not the Query, to Catch a GraphQL N+1

Counting batch loader calls instead of measuring response time helps catch GraphQL N+1 problems early. Developers often miss the issue by seeing snappy response times with small datasets and single loads. The real problem surfaces when the same query runs in production with larger datasets and remote storage. The solution is to observe the number of times a batch loader is called, which should remain constant regardless of dataset size.

Create a mock server that records batch sizes every time the batch loader function is called. Then, add an assertion to check if the largest batch size matches the number of unique keys in the response. If a query asks for ten distinct authors, the batch size should be ten, not ten separate batches of size one. This method works as a regression gate, independent of the model, network, or intuition about performance.

Start with a resolver map treating authors as remote resources and a get_author_batch function that logs its input length. Then, execute a generated corpus of queries that traverse the nested relationship in various ways. The model can produce awkward cases to test inefficient resolvers. A simple loop over generated queries and a mock server exposing batch logs can be run in CI.

The technique is useful for finding common structural bugs in hand-written resolvers that unintentionally cause nested loops. Remember, this is not meant for tuning latency or proving endpoint speed.