Skip to content

Commit ce12e05

Browse files
authored
Add notes for July primary WG (#1329)
1 parent a1cd039 commit ce12e05

File tree

1 file changed

+85
-0
lines changed

1 file changed

+85
-0
lines changed

notes/2023/2023-07.md

Lines changed: 85 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,85 @@
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

Comments
 (0)