[rawling]

When my tech lead decided we were going to move to GraphQL, one of the reasons I was told it was great was because it solves/avoids the n+1 problem.

But from this it sounds like that's something you have to detect and code for directly... which we'd have happily done in the existing code anyway?

[e1g]

GraphQL eliminates the n+1 problem for the client by pushing it to the server. Generally, the client<->backend connection is slow and spiky, and the backend<->db connection is fast and stable, so this trade-off made sense for Facebook as they had more and more mobile users connecting via 3G networks in developing countries.

[SkyPuncher]

N+1s are a fundamentally a data modeling and querying issue.

People who complain about GraphQL having a lot of N+1s are complaining about their lack of fundamental knowledge. You can build a GraphQL with minimal N+1s and you can build a “standard” API with loads of N+1s

[latchkey]

I made this related comment about N+1 on a netflix graphql post a few days ago... some of the responses might be interesting to you.

https://news.ycombinator.com/item?id=36382212

[gavinray]

  > one of the reasons I was told it was great was because it solves/avoids the n+1 problem

So, the thing about GraphQL is that it's a _specification_, in the same way that REST or gRPC are specifications.

There's nothing inherent in either GraphQL or REST that admits or prevents the N+1 problem. You have endpoints with business logic (or in GQL's case, "resolvers") and there's no telling what's inside of those methods code.

It's true that GraphQL was built to integrate with tools like a "Dataloader" to solve "N+1", but you could just as validly be using a Dataloader in your REST or gRPC API endpoints.

[throwaway2990]

Sorry to hear you have an ill informed tech lead :(

[swid]

I have used Dataloaders in the past in both Go and Typescript and it just about solves the issue automatically. Dataloader is a specific library that is copied for different languages that allows you to write code that looks like N+1, but it will group the N part into batches, so it becomes just 1+1. It’s kind of weird to explain, but it should be easy to understand once you start working with them.

[ttfkam]

Alternatively you can use things like Postgraphile or Hasura and truly eliminate both N+1 and 1+1. CTEs and JOINs really are underrated. Both solutions allow easy review of the SQL they generate, they do all of the CRUD work for you, and new resolvers are just a function away.

MySQL isn't invited to the party however. Just Postgres.

[troupo]

Dataloaders replace N+1 with E queries (where E is the number of separate entity types to fetch) and an in-memory merging of all datasets (huge if you're not careful).

They are a solution, but not necessarily a good one. And GraphQL doesn't lend itself to goos solutions.

[swid]

N+1 only makes sense for E=2. For each parent in the list, fetch the child’s data. If there were multiple children, or if the children had their own children fetched 1 at a time, it would no longer be N+1.

So I think 1+1 (or 1+N/batch size) is still correct.

[andrewingram]

It doesn’t solve it, but it lets you build a system that solves it for all future queries going forward. Think of it as a platform for taking endpoint specifications (ie GraphQL queries) and satisfying them efficiently. You have to build the part which makes it efficient, but once that’s done, it’s done.