Skip to content

Latest commit

 

History

History
115 lines (100 loc) · 6.2 KB

2023-11.md

File metadata and controls

115 lines (100 loc) · 6.2 KB
Raw

GraphQL WG Notes - November 2023

Watch the replays: GraphQL Working Group Meetings on YouTube

Primary

Agenda: https://github.com/graphql/graphql-wg/blob/main/agendas/2023/11-Nov/02-wg-primary.md

Determine volunteers for note taking (1m, Lee)

  • [silence]
  • (And Benjie, but late due to daylight savings time change)

Review prior secondary meetings (5m, Lee)

  • No updates

Review previous meeting's action items (5m, Lee)

  • Lee and Benjie will be garbage collecting inactive items after this meeting
  • Lee: Many dead items are cases where the champion has gone dormant.

GraphQL-over-HTTP is advancing to stage 2 (5m, Benjie)

  • If folks have objections, now is the time to raise them
  • Benjie: Issues that are generic to HTTP (such as cookies etc) should not be part of the spec
  • Lee: But our non-conforming portions of the spec can still give guidance, esp. things where GraphQL might be especially likely to hit
  • Lee: GraphQL-over-HTTP is officially stage 2 draft
  • ACTION: non-binding notes about security
  • ACTION: make sure discoverable
  • ACTION: make sure governance docs are all aligned

Support non-list variables for list arguments (15m, Benjie)

  • Representing on behalf of @Shane32
  • Shane: I noticed that variable is not interchangeable with a literal. Specifically there is a difference when it comes to coercion
  • Lee: I’m trying to remember why we did this. I have a recollection that we made this decision on purpose.
  • Lee: Coercion is done when we process variables for the operation, not at the time they are passed to the field. I think that’s why this [the observed behavior] is the case. I stated this as an assumption, but I mean it as a question. Does that sound right?
  • Shane: so we’re describing an implementation?
  • Lee: yes, but I suspect it’s also described that way in the specification
  • Benjie (in chat): Relevant spec link (I think): https://spec.graphql.org/draft/#sec-Coercing-Field-Arguments 5.f
  • Lee (in chat): Yes Benjie - note that variableValues is used as a value directly without any coercion steps https://spec.graphql.org/draft/#sel-LANTHHCJFLFFCAACGB5sT
  • An extremely loose paraphrase of what Lee said with some additions from Benjie:
    • When you process a request, the variableValues are the raw inputs from the request. Step 2, we coerceVariableValues which uses the types of the arguments declared in the operation, and we coerce these raw values to give coerced values. These are then safe to use for these exact types.
    • When we use it in CoerceArgumentValues we can lift the already coerced (and thus safe) value and use it directly. But it doesn't get coerced again, so the type must match exactly. (Coercing again may be unsafe.)
  • Lee: we could move this into CoerceArgumentValues If the types don't match then we may need to do some value wrapping to ensure the value is type aligned, but this will introduce an overhead for every field execution.
  • Is it worth it?
  • Sorting is a use case; change from sortBy: Sort to sortBy: [Sort!] (e.g. sortBy: [CITY, NAME]). Gives flexibility to schema evolution.
  • Lee: complexity is a concern

Strict Semantic Nullability (15m, Jordan)

  • Align on next steps
  • Meta's tentative plans to explore this space
  • Jordan: thanks to Lee for taking my broad points and expressing them a lot better. I might close my thread in favour of Lees.
  • There's been great discussion, I'd like to be clear on next steps.
  • What can we do at Meta to drive this forward? I want to share what I'm thinking and seek feedback. Lee, what do you think are next steps?
  • (This specifically relates to "Strict Semantic Nullability" #1410 )
  • Lee: the breakthrough from my perspective is that we realise that Benjie's proposal (took me a while to understand the *) - I understand that proposal a lot more now, and I started writing the draft based on what I thought might be right and wasn't sure what would be problems, and I effectively came up with the same solution Benjie came up with as I solved the issues. Really not clear which proposal is better right now.
  • There are two very different approaches to address the two phases of nullability: disabling bubbling, and introducing a new type of thing.
  • Initially I was convinced that disabling bubbling would solve this problem; but now I'm not - I think it will make schema designers favour one solution over another. The community is over-using ! non-null wrapping type, we should use this even less by introducing another nullability type.
  • Essentially we want a type that generates localized errors, but introduces the concept of whether it is allowed to be semantically null or not.
  • General idea: we're going to introduce a new thing. Some fields can return a value, or a null (independent of whether they error). Some fields can return the type (NOT A NULL) but may or may not error. The payload may still contain null because an error occurred.
  • Benjie posted about the syntaxes being discussed: #1410 (comment)
  • Benjie proposed an asterisk for the new type, I'm proposing that ? indicates that null is allowed.
  • At a high level: ? is familiar, easy to learn. If the most common usage is non-nullable, then default state is that they're unmodified.
  • Pro of Benjie is that existing type system continues to work how it does, we're only introducing a new thing. But if the new thing is the most common case, we're going to see that come up a lot. And we need a way to represent this in a way that people can understand it.
  • Jordan: that matches my expectation. Three different tiers, Benjie's has the smoothest adoption, but potentially a noisy/confusing looking SDL. Lee's has a good end state but a tricker to navigate migration. Disable null bubbling is a potentially better end state, at the expense of being non-viable for migration.