Skip to content

Commit 73d3b9b

Browse files
benjiebenjie
authored
Add notes for November primary WG (#1426)
1 parent e751a03 commit 73d3b9b

File tree

1 file changed

+115
-0
lines changed

1 file changed

+115
-0
lines changed

‎notes/2023/2023-11.md

Lines changed: 115 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,115 @@
1+
# GraphQL WG Notes - November 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/11-Nov/02-wg-primary.md](https://github.com/graphql/graphql-wg/blob/main/agendas/2023/11-Nov/02-wg-primary.md)
10+
11+
## Determine volunteers for note taking (1m, Lee)
12+
13+
- [silence]
14+
- (And Benjie, but late due to daylight savings time change)
15+
16+
## Review prior secondary meetings (5m, Lee)
17+
18+
- No updates
19+
20+
## Review previous meeting's action items (5m, Lee)
21+
22+
- Lee and Benjie will be garbage collecting inactive items after this meeting
23+
- Lee: Many dead items are cases where the champion has gone dormant.
24+
25+
## GraphQL-over-HTTP is [advancing to stage 2](https://github.com/graphql/graphql-over-http/pull/275) (5m, Benjie)
26+
27+
- If folks have objections, now is the time to raise them
28+
- Benjie: Issues that are generic to HTTP (such as cookies etc) should not be
29+
part of the spec
30+
- Lee: But our non-conforming portions of the spec can still give guidance, esp.
31+
things where GraphQL might be especially likely to hit
32+
- Lee: GraphQL-over-HTTP is officially stage 2 draft
33+
- ACTION: non-binding notes about security
34+
- ACTION: make sure discoverable
35+
- ACTION: make sure governance docs are all aligned
36+
37+
## Support non-list variables for list arguments (15m, Benjie)
38+
39+
- Representing on behalf of @Shane32
40+
- Shane: I noticed that variable is not interchangeable with a literal.
41+
Specifically there is a difference when it comes to coercion
42+
- Lee: I’m trying to remember why we did this. I have a recollection that we
43+
made this decision on purpose.
44+
- Lee: Coercion is done when we process variables for the operation, not at the
45+
time they are passed to the field. I _think_ that’s why this [the observed
46+
behavior] is the case. I stated this as an assumption, but I mean it as a
47+
question. Does that sound right?
48+
- Shane: so we’re describing an implementation?
49+
- Lee: yes, but I suspect it’s also described that way in the specification
50+
- Benjie (in chat): Relevant spec link (I think):
51+
https://spec.graphql.org/draft/#sec-Coercing-Field-Arguments 5.f
52+
- Lee (in chat): Yes Benjie - note that variableValues is used as a value
53+
directly without any coercion steps
54+
[https://spec.graphql.org/draft/#sel-LANTHHCJFLFFCAACGB5sT](https://spec.graphql.org/draft/#sel-LANTHHCJFLFFCAACGB5sT)
55+
- An extremely loose paraphrase of what Lee said with some additions from
56+
Benjie:
57+
- When you process a request, the `variableValues` are the raw inputs from the
58+
request. Step 2, we `coerceVariableValues` which uses the types of the
59+
arguments declared in the operation, and we coerce these raw values to give
60+
coerced values. These are then safe to use for these exact types.
61+
- When we use it in `CoerceArgumentValues` we can lift the already coerced
62+
(and thus safe) value and use it directly. But it doesn't get coerced again,
63+
so the type must match exactly. (Coercing again may be unsafe.)
64+
- Lee: we could move this into `CoerceArgumentValues` If the types don't match
65+
then we may need to do some value wrapping to ensure the value is type
66+
aligned, but this will introduce an overhead for every field execution.
67+
- Is it worth it?
68+
- Sorting is a use case; change from `sortBy: Sort` to `sortBy: [Sort!]` (e.g.
69+
`sortBy: [CITY, NAME]`). Gives flexibility to schema evolution.
70+
- Lee: complexity is a concern
71+
72+
## Strict Semantic Nullability (15m, Jordan)
73+
74+
- Align on next steps
75+
- Meta's tentative plans to explore this space
76+
- Jordan: thanks to Lee for taking my broad points and expressing them a lot
77+
better. I might close my thread in favour of Lees.
78+
- There's been great discussion, I'd like to be clear on next steps.
79+
- What can we do at Meta to drive this forward? I want to share what I'm
80+
thinking and seek feedback. Lee, what do you think are next steps?
81+
- (This specifically relates to "Strict Semantic Nullability"
82+
https://github.com/graphql/graphql-wg/discussions/1410 )
83+
- Lee: the breakthrough from my perspective is that we realise that Benjie's
84+
proposal (took me a while to understand the \*) - I understand that proposal a
85+
lot more now, and I started writing the draft based on what I thought might be
86+
right and wasn't sure what would be problems, and I effectively came up with
87+
the same solution Benjie came up with as I solved the issues. Really not clear
88+
which proposal is better right now.
89+
- There are two very different approaches to address the two phases of
90+
nullability: disabling bubbling, and introducing a new type of thing.
91+
- Initially I was convinced that disabling bubbling would solve this problem;
92+
but now I'm not - I think it will make schema designers favour one solution
93+
over another. The community is over-using `!` non-null wrapping type, we
94+
should use this **even less** by introducing another nullability type.
95+
- Essentially we want a type that generates localized errors, but introduces the
96+
concept of whether it is allowed to be semantically null or not.
97+
- General idea: we're going to introduce a new thing. Some fields can return a
98+
value, or a null (independent of whether they error). Some fields can return
99+
the type (NOT A NULL) but may or may not error. The payload may still contain
100+
null because an error occurred.
101+
- Benjie posted about the syntaxes being discussed:
102+
https://github.com/graphql/graphql-wg/discussions/1410#discussioncomment-7208784
103+
- Benjie proposed an asterisk for the new type, I'm proposing that `?` indicates
104+
that null is allowed.
105+
- At a high level: `?` is familiar, easy to learn. If the most common usage is
106+
non-nullable, then default state is that they're unmodified.
107+
- Pro of Benjie is that existing type system continues to work how it does,
108+
we're only introducing a new thing. But if the new thing is the most common
109+
case, we're going to see that come up a lot. And we need a way to represent
110+
this in a way that people can understand it.
111+
- Jordan: that matches my expectation. Three different tiers, Benjie's has the
112+
smoothest adoption, but potentially a noisy/confusing looking SDL. Lee's has a
113+
good end state but a tricker to navigate migration. Disable null bubbling is a
114+
potentially better end state, at the expense of being non-viable for
115+
migration.

0 commit comments

Comments
 (0)