Skip to content

Latest commit

 

History

History
134 lines (118 loc) · 6.95 KB

2023-06.md

File metadata and controls

134 lines (118 loc) · 6.95 KB
Raw

GraphQL WG Notes - June 2023

Watch the replays: GraphQL Working Group Meetings on YouTube

Primary

Agenda

  1. Agree to Membership Agreement, Participation & Contribution Guidelines and Code of Conduct (1m, Lee)
  2. Introduction of attendees (5m, Lee)
  3. Determine volunteers for note taking (1m, Lee)
  4. Review agenda (2m, Lee)
  5. Review prior secondary meetings (5m, Lee)
  6. Review previous meeting's action items (5m, Lee)
  7. Default Value Validation Status Check (5m, Yaacov)
  8. Clarification on Nested List Input Coercion (5m, Abhinand)
  9. CollectSubFields (30m, Yaacov)
  10. @deprecated on OBJECT - next steps (15m, Stephen)

Determine volunteers for note taking

  • Yaacov, Stephen

Review prior secondary meetings

Default Value Validation Status Check (5m, Yaacov)

  • Yaacov: quick status check
    • Awaiting Lee’s review
    • Benjie has spec changes as a PR. Awaiting review
    • Which gets in first? Incremental delivery or this?
  • Ivan: This depends on schema coordinates. What is the status of schema coordinates?
    • Michael: schema coordinates is ready
  • Ivan: Champions. Start at the top of the stack, one PR at a time.
  • Yaacov: Next step - see if we can break down further. I’ll take that as an action item
    • Ivan: Maybe break out things that are purely GraphQL-js

Clarification on Nested List Input Coercion (5m, Abhinand)

  • Abhinand: I noticed a bug and created an issue.
  • Yaacov: We do automatic coercion to a list when you provide a single value.
    • At the time that this was clarified in the spec, a second question was asked: What happens with a list of lists when you pass a single value?
    • The answer was that we should also wrap this in a nested list.
    • We have a table that says when a doubly nested list is expected and a singley nested list is provided there is an error. Is that what we want?
  • Michael: Would be great to have Lee’s insight on history of why this is in the spec like this
  • Ivan: Relation to javascript coercion
  • Yaacov: It’s already released in graphql-js with this behavior (not erroring). If we changed it to match the spec, would that break existing users?
  • Ivan: The spec is usually the source of truth. I’d consider changing graphql-js safer than changing spec.
    • This would be introduced as a semver breaking change. Include in release notes.
    • Same thing happened in apollo. Initially impls were based on graphql-js but more and more clean room impl based on the spec.
  • Michael: Usually you start with the spec and look at graphql-js for clarification on some algorithms
  • Ivan: To change the spec, it’s adding a feature. A feature needs a string use-case
    • Michael: I agree. Lots of other implementation would have implemented based on the table
  • Michael: Let’s add to secondary meeting
  • Yaacov: Once we’ve confirmed that we want to stick with the table we could make an editorial change to clarify wording around the table in the spec

CollectSubFields (30m, Yaacov)

  • Yaacov: (Some slides with motivation for PR)
    • incremental delivery with deduplication
  • Yaacov: Action - review spec text. No hurry to merge now. The use-case is upcoming but hasn’t arrived. Later spec change will be built on this.
  • Ivan: Safe to say this is a Strawman. There is usefulness in it.

@deprecated on OBJECT - next steps (15m, Stephen)

  • Stephen:
  • graphql/graphql-spec#997
  • Today we can deprecate fields, but not objects. Generally, deprecation is for clients, not servers; we are trying to communicate to clients that they need to change, i.e. that they need to stop requesting the deprecated field.
  • Changes with types have fewer client-required changes -- but they do have at least some!
  • Operations can mention types also -- they can spread a fragment on a type that implements an interface to request specific fields only if the returned type is the spread type, i.e.:
  • “ ... on SomeObject { someField }” where the return type of the field is SomeInterface and SomeObject implements SomeInterface.
  • A server cannot remove the SomeObject type unless the operations referencing it are updated, and so it would be good for servers to be able to encourage operations to stop using the type via the deprecated directive just like with fields.
  • Michael: I will try to implement it within HotChocolate and provide feedback.
  • Ivan: I will add a link to a rule that needs to be updated to detect duplicate usages; the rest looks pretty straightforward.
  • Ivan: Downside to the current proposal => might one assume that if ..... <notetaker dropped>
  • Action items:
    • Michael to implement in HotChocolate
    • Added validations in graphql-js
    • Next time, discuss moving to Stage 2