[Bug?]:

[efe-pullflow]

What's not working?

I'm working on some query optimization and noted that qraphql resolvers are all called when the data is already present. For routinely accessed relations, we use Prisma to load the relation with the original query, as follows:

const result = (await db.requirement.findMany({ include: { actionBy: true, }, })) When putting Prisma into query logging mode, I noted that we were querying the actionBy relation multiple times.

Adding the following to the actionBy resolver confirmed this, as the console log was generated n times for each row in the original query.

actionBy: (_obj, { root }) => { console.log('actionBy resolver') return db.requirement.findUnique({ where: { id: root.id } }).actionBy() },

Doing the following resolved the issue.

actionBy: (_obj, { root }) => { if ('actionBy' in root) return root.actionBy return db.requirement.findUnique({ where: { id: root.id } }).actionBy() },

Shouldn't our graphql server do this check by default? Is this a Helix issue?

Thanks! I appreciate it!

How do we reproduce the bug?

N/a that I know of

What's your environment? (If it applies)

No response

Are you interested in working on this?

• [X] I'm interested in working on this

[pullflow-ai[bot]]

The issue describes unexpected behavior with GraphQL resolvers and Prisma, suggesting it might be a bug. However, there is no clear reproduction path provided, which means more information is needed to confirm and reproduce the issue.

[pullflow-ai[bot]]

Hi @efe-pullflow, I'm pullflow-ai, here to help with your issue.

From your description, it seems like you're encountering repeated resolver calls for the actionBy relation, which you've mitigated by checking if the data is already present in the root object. This is a common pattern to avoid unnecessary database queries.

Regarding your question about whether the GraphQL server should perform this check by default, it's generally not the default behavior in most GraphQL servers. The server typically resolves fields as requested by the query, unless explicitly optimized by the developer. This is because the server doesn't inherently know if the data is already available unless you provide that logic, as you did.

As for whether this is a Helix issue, it might not be directly related to Helix but rather how resolvers are typically implemented and optimized.

I suggest checking the documentation or community discussions for any existing patterns or middleware that might automate this process.

Let me know if you need further assistance or if there's anything else you'd like to explore!