GraphQL WG Notes - July 2023

Watch the replays: GraphQL Working Group Meetings on YouTube

Primary

NOTE: YouTube videos are now up to date, Benjie has semi-automated the upload process so we should be able to keep them much more in sync in future

June WG Secondary, APAC
June WG Secondary, EU
Meetings have been cancelled recently due to lack of agenda - are they still needed? Yes, just everyone is busy on @stream/@defer right now.

Ready for review
All open action items (by last update)
All open action items (by meeting)
Lots of other things are still on the back burner: client controlled nullability, fragment isolation, input unions / @oneOf, schema coordinates, etc - at the moment most contributor work is going into the incremental delivery work.
oneOf was recently merged to graphql-js. Has been supported in HotChocolate for 1.5 years

Issue with CCN was around bubbling and syntax. Main issue is that Alex isn't currently able to champion it, but was held back by slow interactions with Relay team - would be great to get faster feedback/iteration.
Clients like Relay won't be able to take advantage of CCN without compiling it away and reimplementing on the client to give fragment isolation.
Relay can interpret the developer demand rather than passing it through, and already does similar things with client-side directives, so we could see CCN as just a tool to be enabled by frameworks.
To merge CCN before fragment modularity, we need to be sure it won't block fragment modularity in future.
Consensus was that it's okay for Relay to wipe it all away, but if all clients have to do that it would lose a lot of its value.

TSC mailing list was out of date. Benjie and Jory have been working together to get things up to date, but we're concerned we don't have the best email address for TSC members. TSC members: please send Benjie (DM on Discord, Twitter, or email him) your best email address.
TSC members: if you're not in the TSC chat in Discord, please reach out to Benjie (via Discord).
Are we using the right communication channels? Should we re-introduce slack but on a smaller basis for just project chat? Probably not, because WG work should be open.

Early execution kicks off resolver execution for deferred fields before the previous response is finished building.
Deferred execution wants until the previous response is finished before running resolvers for deferred fields.
Deferred execution can increase total request latency.
Early execution can cause the initial payload to be slower.
We could indicate to resolvers that they're deferred and allow them to make choices based around this.
With deferred execution, there's significantly reduced complexity around error boundaries/bubbling - things will simply not queue to execute in the first place.
What should we specify?
If we specify deferred execution then people might write queries that depend on that, and if we do early execution it might break this expectation.
[All participants were very involved in the discussion, so no-one was able to take further notes. Please see the YouTube video https://www.youtube.com/watch?v=mHp-hMMSacE ]