What is the N+1 Problem in GraphQL?
A crash course on a surprisingly common problem
Once you get beyond the basics of GraphQL, you’ll likely hear people talk about the “N+1 problem.” This might seem scary, it does sound like O(N) notation, which is usually the last thing you hear before your whiteboard interview implodes. But, rest assured this is a simple concept hiding behind a computer science-y name.
The Situation in Question
Let’s say I have a DB of authors and their books, a simple “has many” relationship. Now, I want to get all my authors, and all their books. In REST, you’d make a route that uses your ORM of choice to do something along the lines of:
handler: async () => ORM.getAuthors().getTheirBooks();
Under the hood, it would execute 2 queries: one to get all the authors, and one to get all their books. To use pseudo SQL it would be like:
-- pretend this returns 3 authorsSELECT *
WHERE author_id in (1, 2, 3); -- an array of the author's ids
2 queries. Boom. Done. Since the ORM gets all the ids from the first query, matching all the relationships is easy with the second.
Why GraphQL has trouble with this
Here’s the issue, this only works because your second query already had a list of every
author_id. GraphQL doesn’t work that way since each resolver function really only knows about its own parent object (don’t worry about context right now). That means your ORM won’t have the luxury of a list of author IDs anymore.
So if we took that same request from above and put it into a GraphQL query:
The first layer could have a resolver that hits the DB once and gets all the authors, but that’s it. In the next layer the
books resolver can’t use all those results at once to find all the books. Each book resolver would only get it’s own parent author. This means our ORM would have to hit the DB from one resolver at a time. Here’s some pseudo code for the GraphQL version: