Hi, I’ve recently been working on optimizing a Gra...
# prisma-client
s
Hi, I’ve recently been working on optimizing a GraphQL API and the age old n+1 problem and I came across this

video

to see how Prisma does it. In the video, Tim uses Prisma’s Fluent API to fetch the related fields and he mentions that Prisma makes use of the dataloader pattern. But, based on previous testing of my API, in which I don’t use the Fluent API, the requests weren’t batched. I then converted my queries to use the Fluent API, and voila, the requests were now batched! However, there doesn’t seem to be a mention of this anywhere in the docs. It’s also mentioned that the main difference between the two is that Fluent API makes two separate requests, which could seem inefficient at first… i.e. until you realise that it batches requests (which is awesome!) In my opinion, a section could be added to differentiate between using the Fluent API and the general API and also give a brief intro to the dataloader pattern and explain how Fluent API batches requests. Thoughts?
👍 1
👍🏾 1
n
Hey Shreyas 👋 thanks a lot for raising this! We are indeed currently already working on a docs page that explains Prisma's DataLoader in more detail (here's the GitHub issue you can follow to track this). However, I agree with you that this should be noted in the Fluent API section as well, so I created a GitHub issue that will be picked up by our docs team! Thanks again and let us know if you have any more questions 🙂
👍 1
r
There’s also an issue here that was fixed in the latest version of Prisma i.e.
2.17.0
so could you try this on the latest version?
s
so I created a GitHub issue that will be picked up by our docs team!
Awesome!
There’s also an issue here that was fixed in the latest version of Prisma i.e. 
2.17.0
 so could you try this on the latest version?
I think I didn’t make myself clear. When I used a query with
findUnique
to resolve the value of the field itself, there was no batching (which is expected). Whereas, when I used a
findUnique
query on the parent object and queried for the relation using the Fluent API, the queries were batched, which is again the expected outcome. I am currently on
2.17.0
and I think that’s why I didn’t face the problem mentioned in the issue 🙂
👍 2
s
This is great!