Hacker News Reader

Comment by brap | Hacker News Reader

> 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.

View on HN

in 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.

I 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.

Could you test this and get back to us with the results?

There are pretty extensive docs on how Prisma optimises n+1 queries: https://www.prisma.io/docs/guides/performance-and-optimizati...

The 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?

No 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.

Very interesting, thank you. Is there a way for me to monitor what Prisma is doing in my use case?

using `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

Awesome, 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 } }))

Pleeeeeease 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).

If 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

For the interested, here's an article that explains how the dataloader manages to pull this off https://www.mikealche.com/software-development/advanced-prom...

This isn't true. Prisma currently only supports batching of findUnique queries: 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

Is 933 open issues a warning sign? Seems excessive.

Reply on news.ycombinator.com