Skip to content

Latest commit

 

History

History
154 lines (131 loc) · 7.9 KB

2024-07.md

File metadata and controls

154 lines (131 loc) · 7.9 KB
Raw

GraphQL WG Notes - July 2024

Watch the replay: GraphQL Working Group Meetings on YouTube

(Rescheduled due to July 4th celebrations.)

Determine volunteers for note taking (1m, Host)

  • Jordan
  • Everyone, feel free to help!

Review agenda (2m, Host)

  • 4th of July was canceled

Review prior secondary meetings (5m, Host)

  • No secondary meetings

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

  • No items ready for review

Directive validation: require at least one location (5m, Benjie)

  • Presented by James
  • Update spec to explicitly clarify that at least one location must be specified. Currently it’s implicitly specified in the grammar.
  • Benjie: I see this as an editorial change and does not need to go through the full
    • Michael Staib seconds this
  • James: Adding this to GraphQL Java was not a fully trivial change. Unclear what other implementations might be impacted
  • Michael: But you could never use the directive anywhere right?
  • Benjie: It’s a bug in the spec. We should make other implementations aware, but we can accept this as editorial. I will take of getting this merged.

@oneOf update (10m, Benjie)

  • Adds polymorphism to input types. Proposed in 2021, oneOf multiple proposals. Like for being least breaking.
  • Been implemented in GraphQL JS and backported to stable release
  • Benjie: Go and use it
  • Benjie: Currently RFC 2, would love to move it to RFC 3 in the next few months
  • Jordan: What places are you looking feedback for? What should we look out for?
  • Benjie: personal concern: is it the good solution? Feels like we should mirror input and output. Now is a good time for a better, more symmetrical solution.
  • Michael: People are already doing this in the wild.
  • Michael: There was a cleaner proposal for inputUnion which looked good, but introduced a lot of other problems, like __typename on input types.
  • Benjie: I have personally dragged my heels on this because I would love us to adopt the struct type and that might solve this problem but it got feedback that it was too broad. Struct and oneOf could coexist, just something to be aware of.

Define data collections (5m, Benjie)

  • Benjie: This PR is ready for review. Previous feedback has been addressed.

Adding "extensions" to request (5m, Benjie)

  • Benjie: Split into two PRs:
    • Define names of params of GraphQL request (merged)
    • Should we add this additional definition of extensions (the current PR)
  • Benjie: Other transports that use different encodings need to understand what constraints there are on the extensions data.
  • Benjie: Specifies that there may or may not be extensions and if it does exist it should be a map.
  • Martin: Do we want to reserve namespaces in the extensions map for sub-specs? Would allow sub-spec authors to add their own metadata without needing to make it a GraphQL core spec change.
  • Benjie: GraphQL Foundation owns the namespace. We can probably have those conversations globally since there’s enough overlap between main spec WG and sub-spec authors.
  • Martin: People are using top level names for persisted documents (documentID)
  • Benjie: I think GraphQL spec additions should live outside of extensions and leave extensions for users

Semantic Nullability Schema - update from Nullability WG (45m, Benjie)

  • Benjie: Slides (previously presented at nullability WG sub-WG meeting)
    • Notes not taken from slides presentation. See slides.
  • Benjie: We bring it to this group for feedback
  • Lee: Couple high level thoughts
    • We’re going to lose people on the terminology. We are going to need to teach people outside of this group. I don’t have any good suggestions there but I think there’s more work to be done on communication here.
      • Benjie: The ideas is that consumers don’t need to think about this much. Outside of client frameworks and server frameworks. In most cases they could even continue to hide the pragmified schema from product engineers.
    • I am wary of this being a document thing. In many cases a schema’s source of truth is introspection and SDL is just a serialization of that.
      • Benjie: In introspection we would allow you to get the richer version of the schema, or the simpler bubbling/non-null bubbling versions. SDL is just a serialization that represents this.
  • Lee: Despite the fact that you presented the bike shed of syntax as Lee’s proposal vs Benjie’s proposal, I found your justification compelling
  • Michael: I also agree with syntax one since it’s less churn in the ecosystem
  • Martin: Client developers tend to make implicit guesses about which fields are actually nullable (because right now the schema does not actually tell them)
  • Lee: A likely bad idea, but just to think about: Could we do away to the unadorned type all together? T!, T? and T!!.
    • Making non-nullable (semantic or otherwise)
    • Benjie: I like this but it’s very noisy. Especially for things like lists
  • Jordan: Would be interesting to get insights from large schemas
  • Jordan: At Meta, nullability is quite common, partly due to DB integration and ORMs returning nullable types
  • Benjie: What about Input Types? What about optional vs nullable.
  • Benjie: what is the expectation of !! for inputs?
  • Lee: The scope of input types is relatively different. The story is simpler on the input side of things. There are no errors. Leave the input types alone.
  • Lee: To preserve option value we should encode in the grammar that you can’t use !! in input types
  • Jordan: I think we can dismiss regex as a valid migration strategy. You need a parser to avoid changing comments or string literals
  • Jeff: Lets think about how we might use pragmas in the future. How else might we want to use pragmas?
    • In 10 years would we want a future where we make the pragma the default?
    • Would it be simpler to use a versioning scheme?
  • Benjie: pragma is for breaking syntactic changes. Not used for new features (this can use directives)
  • Benjie: GraphQL requires a non-linear versioning system. We could introduce pragmas with arguments.
  • Jordan: What is the end state. Do we need a list of pragmas at the top of every document?
  • Lee: Does the pragma change the syntax? Or is it how you interpret the document? What happens if you put a !! without the pragma?
  • Lee: should we add document directives?
  • Benjie: where do we define those directives? Do we need to put them in the spec?
  • Martin: some people use extend schema @semanticNullability -> but that’s not working for a single document
  • Jordan: this looks like a v2
  • Lee: It’s going to be really hard to do.
  • Lee: One good thing with the pragma is that it can be a default. You have a document and a list of features at the top.
  • Jordan: It doesn’t have to be exclusive. Versions could be a list of default features that you could enable or disable.
  • Jeff: Nullability seems to be a unique problem. What is it we’re trying to do on a conceptual point of view?
  • Michael: this is a pragma in the SDL. The pragma could be the serialization of the server behaviour.
  • Jordan: is this still worth it? What is the tradeoff?
  • Lee: this is still one of the main gripe of users. It’s opt-in.