Debugging GraphQL N+1 Issues with Open Source Tracing Tools • Hacker News Board

Re: Debugging GraphQL N+1 Issues with Open Source Tracing Tools

#11

Post by swid » Tue, Jul 04, 2023, 5:53 PM UTC

troupo wrote: post #8

swid wrote: post #7

Earlier quoted context omitted.

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.

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.

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.

Re: Debugging GraphQL N+1 Issues with Open Source Tracing Tools

#12

Post by e1g » Tue, Jul 04, 2023, 6:13 PM UTC

rawling wrote: post #3

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?

GraphQL eliminates the n+1 problem for the client by pushing it to the server. Generally, the clientbackend connection is slow and spiky, and the backenddb 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.

Re: Debugging GraphQL N+1 Issues with Open Source Tracing Tools

#13

Post by SkyPuncher » Tue, Jul 04, 2023, 9:53 PM UTC

rawling wrote: post #3

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?

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

Re: Debugging GraphQL N+1 Issues with Open Source Tracing Tools

#14

Post by ttfkam » Thu, Jul 06, 2023, 2:20 PM UTC

swid wrote: post #7

rawling wrote: post #3

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?

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.

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.