Re:Debugging GraphQL N+1 Issues with Open Source Tracing Tools
by swid on Tuesday July 04, 2023 @01:42PM
(#36590036)
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.
[ Parent
| on HN ]
Re:Debugging GraphQL N+1 Issues with Open Source Tracing Tools
by troupo on Tuesday July 04, 2023 @01:45PM
(#36590097)
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.
Re:Debugging GraphQL N+1 Issues with Open Source Tracing Tools
by swid on Tuesday July 04, 2023 @01:53PM
(#36590229)
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
by ttfkam on Thursday July 06, 2023 @10:20AM
(#36616228)
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.