×

SpecNews #5

August 2022 WG

August 2022's working group meeting saw the working group moving closer to changing the meeting cadence, an update on the GraphQL over HTTP Spec, a proposal of a new STRUCT type, musing over evolving the definition of GraphQL, and more discussions around interfaces and unions.

Music by Zen_Man on Pixabay.

Transcript

Benjie
Benjie
Hello GraphQL fans! Welcome to episode 5 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.
Benjie
Benjie
August's meeting saw the working group moving closer to changing the meeting cadence
Jem
Jem
An update on the GraphQL over HTTP Spec,
Benjie
Benjie
A proposal of a new STRUCT type,
Jem
Jem
Musing over evolving the definition of GraphQL,
Benjie
Benjie
And more discussions around interfaces and unions,
Jem
Jem
Here we go!

[0:37] Meeting times and cadence

Benjie
Benjie
The first discussion was meeting times and cadence. Working group meetings were originally three hours long, which was a bit of a slog, and the times were particularly difficult for those in the Asia Pacific timezones. We changed the meeting duration to two hours about a year ago, but attendees from Asia Pacific timezones still weren't attending because the meetings in the summer were starting at 4:00am.
Jem
Jem
If you've listened to a few episodes of SpecNews you've probably gathered that two hours isn't enough for all the agenda items they've been having, so they want to change the meetings again.
Benjie
Benjie

After much discussion, the conclusion was that we'd move to a weekly meeting cadence with 1.5 hour meetings, and we'd alternate the time between 9:30am Pacific one week (an early time, for Europe) and 3:30pm Pacific the next (a later time, for Asia Pacific timezones).

This takes us from two hours a month to six hours a month, so should see us through for a while!

[1:37] GraphQL Over HTTP update

Jem
Jem

Next was Benjie with GraphQL over HTTP. The subgroup wants to advance the spec to stage 2 and are seeking main working group approval. They have requested that attendees review the spec and look at the implementation in JavaScript from Denis, which was written from scratch.

Lee says as it's a companion spec, it doesn't necessarily have to go through these stages. He likes the model of subcommittees owning their own project, with any specs and reference implementations living under the foundation. This approach lets people implement it, and it can live in draft mode while CLAs are signed and gaps in the new spec are found. It can then go through ratification with the TSC when it's finished.

Benjie
Benjie
Ivan raised that the proposed Media Type application/graphql should be the media type for GraphQL documents (i.e. what you'd store in a.graphql file) and suggested that the GraphQL over HTTP spec should maybe use something more like application/graphql-response+json. There were no reservations to this and so the change will be made.

[2:44] The STRUCT type

Jem
Jem
Then back to Benjie again for the STRUCT type. I'll let him explain this one.
Benjie
Benjie
I gave the struct type the backronym "Structured, Type-safe, Returnable and Union-Capable Type" — the idea is that it extends input objects to the output schema, allowing us to safely expose things like directive arguments without having to have clients have their own parsers. It came out of discussions with various working group members about schema metadata, a topic I'm heavily interested in, and also on my work on the@oneOf input union type. I'm hopeful that this type can not only solve the metadata problem for which it was designed, but that it can solve the input unions problem, and even enable new capabilities motivated by real use cases that people have shared in various GraphQL Spec issues on GitHub.
Jem
Jem
Lee pointed out that the type sounds like a panacea and is concerned that it might solve many problems but in an inadequate way. He suggests going back a step and redefining the problem.

[3:50] Redefining GraphQL

Jem
Jem
Next was Roman revisiting the topic of redefining GraphQL. He believes there are two separate definitions of GraphQL contained in the spec, and he's not happy with either. He'd like the definition of GraphQL to centre on GraphQL as a communication protocol between client and server and less on how it is executed. He received a lot of pushback, with Michael pointing out that it's specs like the GraphQL over HTTP spec which are concerned with communication. Lee suggested Roman change his approach from an inwards-out method to outwards-in where he asks for input from other members of the working group on what they feel the domain of the spec is.

[4:27] Unions and interfaces discussion

Benjie
Benjie
Yaacov returned with an update on extending the polymorphic types in GraphQL. This month he's proposing that unions could include other unions or interfaces so long as the union also lists all of the types within that union/interface. The discussion concluded that this would be a maintenance headache and gave greater confidence that Yaacov's previous proposals were closer to the right direction.
Jem
Jem
Lee closed this topic with a warning that without sufficient care this could lead to infinite recursion or recursion loops.

[4:57] Topics for next time

Benjie
Benjie
Two topics were bumped to the next meeting due to a lack of time—
Jem
Jem
—Hopefully something which won't happen when the new meeting cadence has been approved—
Benjie
Benjie
specifying extensions property on requests, the RFC of which can be seen in pull request 976,
Jem
Jem
and reordering and renaming the language and type system chapters of the spec, there's an open discussion on this in the working group repo.
Benjie
Benjie
Yet another packed meeting! That's all from us at Spec News and we bid you a fond farewell.
Jem
Jem
Have a good one!

Subscribe to be notified of new episodes of SpecNews:

« Back to episodes