Replies: 3 comments 2 replies
-
|
I don't know of any one that has looked into this. Thanks for bringing it to our attention. |
Beta Was this translation helpful? Give feedback.
-
|
This jogged a memory for me. A very early version of graphql-java had a BatchedExecutionStrategy Added Jan 18, 2016 - more than 10 years ago - how about that for progressive! I think it did elements of what the Shopify engine is trying to do. However the code is pre Java 6 and hence there is no async CompleteableFuture support in it. It could be worth looking at for inspiration again. If I recall right (and its a long time ago) its problems where more that
So eventually it was removed. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for digging into this! So while I could see ways to follow the spec on errors (e.g. launching costly error propagation on level N only when there is an actually error, like an optimistic locking scheme where we assume no contention), I cannot see a way to not break current instrumentation ordering of callbacks. Yes, the instrumentation is a deal breaker for a lot of people (me included). |
Beta Was this translation helpful? Give feedback.
-
One thing we have learnt over the years is that the "execution strategy" and the "instrumentation" are co-depedent on each other. A "new execution algorithm" MUST have its own Instrumentation because you want "callbacks" on whats happening that "match the shape" of the execution algorithm. If I was to make |
Beta Was this translation helpful? Give feedback.
-
|
Maybe |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi all,
I recently came across Shopify's post on breadth-first GraphQL execution (https://shopify.engineering/faster-breadth-first-graphql-execution) and found it thought-provoking — particularly because some of the patterns they describe match what I've been observing while profiling graphql-java with list queries in the hundreds of elements.
Their analysis of per-field overhead amplification and DataLoader promise proliferation in depth-first execution resonates with me. The Java side has its own equivalents: DataFetchingEnvironment allocations, ExecutionStepInfo chains, and CompletableFuture overhead that scales linearly with list cardinality.
Did someone already looked at this problem from that angle? I think it would be interesting (and useful!)
Beta Was this translation helpful? Give feedback.
All reactions