This is a follow up of issue created at https://github.com/Urigo/graphql-modules/issues/1295
I still have to understand how, but wanted to create the ticket as soon as possible.
Hi!
@maapteh are you able to recreate this bug with just a regular sdl schema?
Is this a bug with wrap or just the way wrap works?
@yaacovCR @maapteh https://github.com/ardatan/graphql-tools/pull/1955
I guess it's one execution per each root-level field so we need to have a dataloader on top or something similar.
It happens because we wrap all root-level resolvers with defaultCreateProxyingResolver and call delegateToSchema on resolver level and it's delegateToSchema that runs executor function.
Should be fixed by batched executor which is (loosely) planned for v7, to be based on Gatsby-style batch execution
This right now is working as designed as far as I can tell but there is room of course for design improvement.
Batch execution is one solution, maybe there are others?
Of course there already is HttpLinkDataLoader which batches as one request not necessarily one operation
Actually, I am not 100% on whether batch execution fixes this issue.
The executor will still be called multiple times, so similar test may fail, but because multiple root fields or multiple operations can be sent as one, there will be only one network request. Would that solve this issue?
When the testcase for #1955 succeeds we know if it will solve it :)
Why do you need the executor to be called once if it uses Data loader to batch and send one request?
Because now our dataloader is not called in the same request/operation. Dataloader only works when it happens in the same tick. But i think its a bug in combination apollo and our used modules and will go back there!
thanks Yaacov. Sorry for reporting here :)
The point is of that issue is that when you wrap the schema with wrapSchema you run executor for each root-level field, which means executing multiple GraphQL operations instead of single one.
Seems to have been addressed within graphql-modules as documented in linked issue above. Closing this issue for now!
When query batching lands, see #1965, another possible workaround may be available.
Available in 6.2.0!
Most helpful comment
Available in 6.2.0!