batchDelegateToSchema
running resolvers twice
#5033
Unanswered
TuurDutoit
asked this question in
Q&A
Replies: 1 comment
-
You use |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I couldn't find an answer to my question in the docs, so I'll try my luck here.
I'm using
batchDelegateToSchema
to resolve a field in my GraphQL API in a more optimized way. This works fine, except for the fact it runs my resolvers twice! I think I understand why it happens, but I'm at a loss on how to stop it from happening.I made a minimal repro here. Given the following query:
This is what happens:
Query.course
Course.pool
. This usesbatchDelegateToSchema
, which essentially runs a sort of "subquery" against the same schema:3. GraphQL resolves
Query.pools
4. For each pool (just 1 in this case), GraphQL resolves
Pool.id
(this logs a message to the console)5.
batchDelegateToSchema
returns the Pool object (crucially: with all of its fields already being resolved!)Pool.id
again (logging a second message to the console)! It just received some object from theCourse.pool
resolver - it doesn't know this object has already been fully processed insidebatchDelegateToSchema
, so it runs the resolvers. GraphQL is "dumb" that way. Is there a way to make it "smart" and not have it rerun the same resolvers again?Does anyone have experience dealing with this? It would probably be useful to add a warning about this in the docs!
Beta Was this translation helpful? Give feedback.
All reactions