You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Recently, while optimizing our API service, we encountered the N+1 problem in our GraphQL resolvers. This issue occurs when a separate database query is executed for each related record, resulting in multiple queries being made to retrieve additional information for associated data.
Upon further investigation, we referred to the Prisma documentation, which provides guidance on addressing this issue (link). It suggests leveraging Prisma features, such as the fluent API, to enable the database to automatically batch requests and reduce the number of queries.
The issue is that, despite following the documentation and implementing these optimizations, the queries to the database are still not being batched as expected.
We are starting to suspect that the way Redwood, or its underlying GraphQL engine, executes resolvers might be interfering with the built-in data loaders provided by Prisma.
In the code above, the same databse instance is shared for all resolvers, where:
constdb=newPrismaClient();
Given the setup described above (using findUnique and the fluent API), automatic batching should function as expected, but for some reason, it does not. Due to the private nature of the project, I cannot share the code directly. However, if a reproduction is needed to test this issue, I am willing to create one and provide it.
What's not working?
Recently, while optimizing our API service, we encountered the N+1 problem in our GraphQL resolvers. This issue occurs when a separate database query is executed for each related record, resulting in multiple queries being made to retrieve additional information for associated data.
Upon further investigation, we referred to the Prisma documentation, which provides guidance on addressing this issue (link). It suggests leveraging Prisma features, such as the fluent API, to enable the database to automatically batch requests and reduce the number of queries.
The issue is that, despite following the documentation and implementing these optimizations, the queries to the database are still not being batched as expected.
We are starting to suspect that the way Redwood, or its underlying GraphQL engine, executes resolvers might be interfering with the built-in data loaders provided by Prisma.
How do we reproduce the bug?
GraphQL schema definition:
Main resolver:
Field resolvers:
In the code above, the same databse instance is shared for all resolvers, where:
Given the setup described above (using
findUnique
and the fluent API), automatic batching should function as expected, but for some reason, it does not. Due to the private nature of the project, I cannot share the code directly. However, if a reproduction is needed to test this issue, I am willing to create one and provide it.What's your environment? (If it applies)
Are you interested in working on this?
The text was updated successfully, but these errors were encountered: