May 2022 WG

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.

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.

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.

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.

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.

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.

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.

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.

Ivan is keen to establish the names before they get merged into GraphQL‐js for fear of future breaking changes.

Yaacov next with a continuation of the asynchronous iterators of iterables topic from last meeting.

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.

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.

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".

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.

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.

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.

Ta ra!