https://www.prisma.io/ logo
Join Slack
Powered by
Really?! What do the mean when they say: > Pris...
# orm-help
l
Really?! What do the mean when they say:
Prisma client has a built-in dataloader, solving the N+1 problem and ensuring the Prisma API is queried efficiently.
🤔 1
d
This is a purely client related issue. If you would issue this query directly to the prisma server, it would indeed use an optimized resolver.
t
@Lars-Jørgen Kristiansen thanks for raising that issue! The logging statements may confuse a bit, but we are indeed using dataloader based batching under the hood. If you e.g. debug the actual payload sent to the server, you will see that instead of 3 http requests, we’re sending something like this:
Copy code
[
{"query": "...", "variables": "..."},
{"query": "...", "variables": "..."},
{"query": "...", "variables": "..."}
]
This is array-based batching aka “Apollo Batching”, as they came up with the idea. Now the next level batching is alias-based batching. That would look like this, using GraphQL aliases:
Copy code
{
  query1: workspace()...
  query2: workspace()...
}
This, however is fairly complicated to implement and such an implementation doesn’t exist in the ecosystem yet. We will pretty soon add this to the Prisma Client, though. Then the client will use these two batching methods together to achieve optimal performance. In case you may wonder, how a few 
ctx.prisma.workspace().workers()
calls may get batched together, you need to understand the JS event loop. In your example, the 
workers
resolver is being executed in parallel, which means that a 
process.nextTick()
callback would be executed after these calls to the client have been done. This under the hood gets batched by the Prisma Client without you noticing anything and sent like that to the server. We could indeed improve the debugging output there, it is quite confusing and should let the user know, that batching is active. Could you create an issue for that in our Github repo https://github.com/prisma/prisma/issues/new?template=feature_request.md ? You can read more about the dataloader pattern here: https://github.com/facebook/dataloader
👍 2
l
Thanks @tim2! I can see now that there is an extra newline in the debug output between the 2 http requests sent.. I will create a feature request to make it clearer!
hey @tim2 sorry to bring this old thread up again, but i'm having big issues with the N+1 problem now.. After debugging this for a while I dont think that prisma really solves the N+1 problem. I understand that it batches queries into one HTTP request, and with alias-based batching it could even do with one graphql query, but it will still do N+1 queries on the database! Is this expected behaviour or bug?
t
Thanks @Lars-Jørgen Kristiansen that is true. In Prisma 2 we’re tackling this problem soon, so switching there might pay off. But what you can do in Prisma 1: Optimize things by hand by using the dataloader library. You could rewrite many 
findOne(id: 5)
into 
findMany(where: { id_in: [1,2,4] })
and them match them back
l
Thanks, The problem with that thou is that I do`nt get the id of the related resource so I cant use dataloader..
Copy code
const resolvers = {
  Query: {
    users: () => prisma.users(),
    messages: () => prisma.messages()
  },
  Message: {
    author: ({ id }) => prisma.message({ id }).author() // To use dataloader here I need the author ID!
  },
  User: {
    messages: ({ id }) => prisma.user({ id }).messages()
  }
};
Happy to hear that prisma 2 will solve this. Maybe you should remove the "solves N+1 problem" from the website/docs? It can bite you pretty hard if you just lean on prisma to handle N+1 and find out late into the project that it does`nt. Appreciate all the work you guys put into prisma and looking forward to 2.0.
3 Views
Open in Slack
PreviousNext
Powered by