|
| 1 | +# GraphQL WG Notes - July 2023 |
| 2 | + |
| 3 | +**Watch the replays:** |
| 4 | +[GraphQL Working Group Meetings on YouTube](https://www.youtube.com/playlist?list=PLP1igyLx8foH30_sDnEZnxV_8pYW3SDtb) |
| 5 | + |
| 6 | +# Primary |
| 7 | + |
| 8 | +Agenda: |
| 9 | +[https://github.com/graphql/graphql-wg/blob/main/agendas/2023/07-Jul/06-wg-primary.md](https://github.com/graphql/graphql-wg/blob/main/agendas/2023/07-Jul/06-wg-primary.md) |
| 10 | + |
| 11 | +## Determine volunteers for note taking (1m, Lee) |
| 12 | + |
| 13 | +- Benjie |
| 14 | + |
| 15 | +## Review agenda (2m, Lee) |
| 16 | + |
| 17 | +- NOTE: YouTube videos are now up to date, Benjie has semi-automated the upload |
| 18 | + process so we should be able to keep them much more in sync in future |
| 19 | + |
| 20 | +## Review prior secondary meetings (5m, Lee) |
| 21 | + |
| 22 | +- [June WG Secondary, APAC](https://github.com/graphql/graphql-wg/blob/main/agendas/2023/06-Jun/07-wg-secondary-apac.md) |
| 23 | +- [June WG Secondary, EU](https://github.com/graphql/graphql-wg/blob/main/agendas/2023/06-Jun/15-wg-secondary-eu.md) |
| 24 | +- Meetings have been cancelled recently due to lack of agenda - are they still |
| 25 | + needed? Yes, just everyone is busy on @stream/@defer right now. |
| 26 | + |
| 27 | +## Review previous meeting's action items (5m, Lee) |
| 28 | + |
| 29 | +- [Ready for review](https://github.com/graphql/graphql-wg/issues?q=is%3Aissue+is%3Aopen+label%3A%22Ready+for+review+%F0%9F%99%8C%22+sort%3Aupdated-desc) |
| 30 | +- [All open action items (by last update)](https://github.com/graphql/graphql-wg/issues?q=is%3Aissue+is%3Aopen+label%3A%22Action+item+%3Aclapper%3A%22+sort%3Aupdated-desc) |
| 31 | +- [All open action items (by meeting)](https://github.com/graphql/graphql-wg/projects?query=is%3Aopen+sort%3Aname-asc) |
| 32 | +- Lots of other things are still on the back burner: client controlled |
| 33 | + nullability, fragment isolation, input unions / @oneOf, schema coordinates, |
| 34 | + etc - at the moment most contributor work is going into the incremental |
| 35 | + delivery work. |
| 36 | +- oneOf was recently merged to graphql-js. Has been supported in HotChocolate |
| 37 | + for 1.5 years |
| 38 | + |
| 39 | +## Client Controlled Nullability (10m) |
| 40 | + |
| 41 | +- Issue with CCN was around bubbling and syntax. Main issue is that Alex isn't |
| 42 | + currently able to champion it, but was held back by slow interactions with |
| 43 | + Relay team - would be great to get faster feedback/iteration. |
| 44 | +- Clients like Relay won't be able to take advantage of CCN without compiling it |
| 45 | + away and reimplementing on the client to give fragment isolation. |
| 46 | +- Relay can interpret the developer demand rather than passing it through, and |
| 47 | + already does similar things with client-side directives, so we could see CCN |
| 48 | + as just a tool to be enabled by frameworks. |
| 49 | +- To merge CCN before fragment modularity, we need to be sure it won't block |
| 50 | + fragment modularity in future. |
| 51 | +- Consensus was that it's okay for Relay to wipe it all away, but if all clients |
| 52 | + have to do that it would lose a lot of its value. |
| 53 | + |
| 54 | +## TSC mailing list |
| 55 | + |
| 56 | +- TSC mailing list was out of date. Benjie and Jory have been working together |
| 57 | + to get things up to date, but we're concerned we don't have the best email |
| 58 | + address for TSC members. TSC members: please send Benjie (DM on Discord, |
| 59 | + Twitter, or email him) your best email address. |
| 60 | +- TSC members: if you're not in the TSC chat in Discord, please reach out to |
| 61 | + Benjie (via Discord). |
| 62 | +- Are we using the right communication channels? Should we re-introduce slack |
| 63 | + but on a smaller basis for just project chat? Probably not, because WG work |
| 64 | + should be open. |
| 65 | + |
| 66 | +## Defer execution model - Early vs Delayed (30m, Rob) |
| 67 | + |
| 68 | +- Early execution kicks off resolver execution for deferred fields before the |
| 69 | + previous response is finished building. |
| 70 | +- Deferred execution wants until the previous response is finished before |
| 71 | + running resolvers for deferred fields. |
| 72 | +- Deferred execution can increase total request latency. |
| 73 | +- Early execution can cause the initial payload to be slower. |
| 74 | +- We could indicate to resolvers that they're deferred and allow them to make |
| 75 | + choices based around this. |
| 76 | +- With deferred execution, there's significantly reduced complexity around error |
| 77 | + boundaries/bubbling - things will simply not queue to execute in the first |
| 78 | + place. |
| 79 | +- What should we specify? |
| 80 | +- If we specify deferred execution then people might write queries that depend |
| 81 | + on that, and if we do early execution it might break this expectation. |
| 82 | +- [All participants were very involved in the discussion, so no-one was able to |
| 83 | + take further notes. Please see the YouTube video |
| 84 | + [https://www.youtube.com/watch?v=mHp-hMMSacE](https://www.youtube.com/watch?v=mHp-hMMSacE) |
| 85 | + ] |
0 commit comments