TL;DR
The N+1 problem is a general data-access anti-pattern that can appear in REST, resolver-based GraphQL, and federated GraphQL at different layers of the stack. WunderGraph’s breadth-first loading approach can help batch cross-subgraph work at the router layer, but it does not remove the need for batching inside subgraphs. Even when the router batches entity references, a subgraph can still reintroduce N+1 if its reference resolvers fetch one record at a time. DataLoader is a common resolver-level fix that provides scheduling-window batching plus request-scoped caching, but joins, eager loading, denormalized views, or a single set-based query can be better when the access pattern is predictable. Detection usually means correlating a GraphQL operation with repeated backend calls using database logs, traces, or APM tools. Traces may surface symptoms before they identify the root cause.
A single API request can quietly fan out into hundreds of backend calls. That is the N+1 problem, and it shows up in REST, monolithic GraphQL, and federated GraphQL alike. The shape is the same in each case. What changes is where the repeated work lands — on the client, at the router, inside a subgraph, or in the database.
