5 ms·
> GraphQL N+1 issues are a thing of the past. Huh, care to explain this one? I’m using Prisma with Apollo Server without doing anything fancy in my resolvers.
by brap 6y ago
> GraphQL N+1 issues are a thing of the past.
Huh, care to explain this one? I’m using Prisma with Apollo Server without doing anything fancy in my resolvers. I just assumed I’m getting N+1 issues but didn’t bother to optimize yet.
- dickfickling 6y agoin short the separate engine process allows them to combine every findX call you make during one tick of the event loop into a single SQL query, following the dataloader pattern, so you don’t have to implement it yourself. i’m sure @nikolasburk can shed some more light if you’re interested.
- eurasiantiger 6y agoI have a feeling that does not work at all in non-trivial scenarios, e.g. if both composite keys and date range matching are required to resolve a reference.
- sbarre 6y agoCould you test this and get back to us with the results?
- sorenbs 6y agoThere are pretty extensive docs on how Prisma optimises n+1 queries: https://www.prisma.io/docs/guides/performance-and-optimization/query-optimization-performance#n1-in-other-contexts https://www.prisma.io/docs/guides/performance-and-optimizati...
- eurasiantiger 6y agoThe examples are still for a trivial case of joining one thing to many things. What about joining one thing to many things that join to many things that join to one thing that joins to many things that join to many things that join to many things?
- Sujan 6y agoNo need to test really - indeed more complicated cases are not covered by this yet. But happy to look at any Github issues with reproduction of cases that are not working, but could or should work to make your life better.
- brap 6y agoVery interesting, thank you. Is there a way for me to monitor what Prisma is doing in my use case?
- dickfickling 6y agousing `new PrismaClient({ log: ["query"] });` it'll log all the actual sql queries it's running, so you'll be able to see if queries are being combined
- brap 6y agoAwesome, thanks! Turns out Prisma wasn’t optimizing my queries, I think it has to do with me not using the sub query API and instead querying tables seperately (e.g posts.findMany({ where: { owner: user } }))
- Sujan 6y agoPleeeeeease open an issue if you have a simple reproduction for this. That will make sure we will make sure this _does_ work (sooner or later, not committing to a timeline here on HN of course :p).
- tehlike 6y agoIf it's optimizing with figuring the calls in a single tick out, one can probably still optimize further by using db specific features, like postgres supports json_agg which let's you not only break n+1 in a way, but also prevents cartesian product explosion with joins
- hnjobaccount 6y agoFor the interested, here's an article that explains how the dataloader manages to pull this off https://www.mikealche.com/software-development/advanced-promises-in-javascript-building-a-simple-dataloader https://www.mikealche.com/software-development/advanced-prom...
- m007850 6y agoThis isn't true. Prisma currently only supports batching of findUnique queries: https://www.prisma.io/docs/guides/performance-and-optimization/query-optimization-performance#solving-n1-in-graphql-with-findunique-and-prismas-dataloader https://www.prisma.io/docs/guides/performance-and-optimizati... There's an issue open for findMany as well, but it hasn't moved in over a year: https://github.com/prisma/prisma/issues/1477 https://github.com/prisma/prisma/issues/1477
- Apofis 6y agoIs 933 open issues a warning sign? Seems excessive.