×

SpecNews #2

May 2022 WG

May 2022's working group saw the return of discussions around higher order abstract types in GraphQL, the availability of a canary release of client-controlled nullability, discussions around the shape of iterables and payloads for defer and stream and the advancement of @oneOf input objects to RFC stage 2. Join hosts Benjie and Jem for the details!

Music by Zen_Man on Pixabay.

Transcript

Benjie
Benjie
Welcome to episode 2 of Spec News
Jem
Jem
keeping you up to date with advances in the GraphQL Spec and related foundation projects.
Benjie
Benjie
We're your bespectacled hosts: I'm Benjie
Jem
Jem
and I'm Jem.

May's working group saw the return of discussions around higher order abstract types in GraphQL
Benjie
Benjie
the availability of a canary release of client‐controlled nullability
Jem
Jem
discussions around the shape of iterables and payloads for defer and stream
Benjie
Benjie
and the advancement of @oneOf input objects" to RFC stage 2.

[0:34] Action Items

Jem
Jem
Action items—following up from Benjie creating a SECURITY policy in the graphql‐wg repo, Benjie suggested extending this policy to all Foundation projects and gained approval to do so.

[0:51] Higher order abstract types

Benjie
Benjie
Yaacov returned with a new proposal following up from the "unions implementing interfaces" proposal from the last working group. This new proposal introduces a new type, the "intersection type", which would allow us to apply tighter constraints to the abstract types used in a GraphQL schema. Yaacov believes that "second order abstract types" would be a good addition to the GraphQL language.
Jem
Jem
One of the issues raised was that this approach could lead to silent failures, where something does not meet the constraints and is unexpectedly silently omitted rather than noisily failing. There is, however, interest in this issue being solved as it allows clients to rely on fields existing on types that are newly added to a union.
Benjie
Benjie
Lee cautioned us that implicit versus explicit is generally a tradeoff against expressiveness—the more expressive you can be, the closer you are to Turing completeness, and you have to do more work to compute the effects of your actions. GraphQL has been designed carefully to make things obvious by just looking at local types—without having to follow chains—and an abstract type over abstract types would break that.
Jem
Jem
This revelation gave greater confidence in Yaacov's original proposal to constrain unions to only include types that implement certain interfaces. Yaacov is going to refine the tests ready for next working group.

[2:18] Client‐controlled nullability update

Benjie
Benjie
Alex returned with an update on the status of client‐controlled nullability: there's a canary release of the functionality in graphql‐js and the latest HotChocolate supports it in .NET too. Apollo are also working on support for it.
Jem
Jem
One of the concerns raised was that applying client‐controlled nullability operators in one fragment may break another fragment that's defined in another part of the codebase; though this isn't something that should stop the proposal, it's definitely a trade‐off worth being aware of.
Benjie
Benjie
Lee tasked Alex with creating discussion threads to help resolve the outstanding questions with the proposals. A discussion around naming arose again, suggesting that "assertion" may be a better name for the bang symbol, and "error boundary" for the question mark symbol.
Jem
Jem
Ivan is keen to establish the names before they get merged into GraphQL‐js for fear of future breaking changes.

[3:15] Defer/Stream: Asynchronous iterators of iterables versus of items

Benjie
Benjie
Yaacov next with a continuation of the asynchronous iterators of iterables topic from last meeting.
Jem
Jem
There was general agreement that if we have batches of data available to us on the backend, we should deliver batches of data to the client—not least because it influences the way that clients will handle these payloads. However, returning iterators where a VALUE would normally be expected—simply because it's a stream—would be surprising and would give a strange developer experience.
Benjie
Benjie
However, enforcing that an iterator is always returned might help avoid developers facing the trap that is client thrashing. At this point, discussion seemed to be relatively javascript‐centric, so was redirected to asynchronous channels.

[4:04] Defer/Stream: Stream payload index format

Jem
Jem
Rob returned with discussion of the index format in stream payloads; it has been established since the last working group that including the index is essential otherwise ambiguities can occur. Since the append‐only mechanism has been ruled out, discussion centered around choosing between "at index", "at indices" and "including the index in the path".
Benjie
Benjie
The conclusion was that the operation is "set at a range, where the range starts at the index given in the path, and the length of the range is the length of the data." Though this makes out‐of‐order delivery and sparse lists trickier, it was agreed that the benefits in terms of simplicity outweighed these concerns.

[4:50] @oneOf input objects RFC

Jem
Jem
Next up was Benjie with a request to advance @oneOf input objects to RFC stage 2: "Draft". Benjie's main hesitation is around intent to extend @oneOf to output types—concerned that if we never choose to add oneOf to output types then the significant differences between @oneOf inputs versus unions and interfaces could make it undesirable. The working group reassured that @oneOf input objects seems to be the better input union solution independent of whether it's available on output or not.
Benjie
Benjie
Having established that, it was clear that the proposal was ready to advance and has been raised to RFC2 status. And with that, the meeting drew to an end a mere one minute over time, and that's all from us at Spec News! We bid you a fond farewell.
Jem
Jem
Ta ra!

Subscribe to be notified of new episodes of SpecNews:

« Back to episodes