Watch the replay: GraphQL Working Group Meetings on YouTube
- Agree to Membership Agreement, Participation Guidelines and Code of Conduct (1m, Lee)
- Introduction of attendees (5m, Lee)
- Determine volunteers for note taking (1m, Lee)
- Review agenda (2m, Lee)
- Review previous meeting's action items (5m, Lee)
- Full Unicode - looking for final approval
- Defer/stream - discuss out of order stream payloads (5m, Yaacov)
- Proposal: move the official GraphQL chat from Slack to Discord (10m, Benjie)
- Main aim: to remove message limits (so we don't lose messages)
- Argument uniqueness RFC (Benjie, 5m)
- On behalf of Ivan
- Spec: Forbid duplicating argument names graphql-spec#877
- graphql-js: Add 'UniqueArgumentDefinitionNamesRule' validation rule graphql-js#3208
- State of GraphQL Subscriptions (Brian Kim, 15m)
- Benjie
- Brian Kim
- Added “State of GraphQL Subscriptions”
- A few items and the 2020-07 project board closed
- Spec change
- GraphQL.js PR has sat unchanged since last month, but was fine-tuned before last month to add additional test cases.
- Up for final approval
- Are there any cases where existing schemas would be broken? Is this change backwards compatible?
- A lot of GraphQL implementations accidentally allow unicode, even the graphql-js reference implementation.
- Minor controversy: We are no longer explicitly banning control characters in documents.
- Moderate controversy: We’re allowing JSON-style encoded surrogate pairs. If we didn’t do this, it would be a breaking change.
- Lee: Moving the PR to approved, pending specification publish.
- Spoke with Andi offline and all is good there.
- See graphql/graphql-js#3165
- Rob: It’s possible in the reference implementation to receive stream/defer payloads out of order (e.g. if an earlier payload takes longer to resolve than a later one, etc).
- Rob: I wasn’t planning to hold things up to wait for delayed things to complete to keep them in order. I’ve not called this out explicitly in the RFC but I should.
- Lee: we should specifically allow for out of order in things that don’t depend on one another, but we should require things to be in order if they do depend on one another. E.g. if there’s a deeply nested @defer that resolves sooner than the parent @defer, does the client just keep hold of it?
- Matt: feels like out of order stream payloads could have a problem, but I can’t think exactly what to look for.
- Lee: we should not allow out of order payloads - either they have an order and they come back in that order, or they don’t have an order and we should make that very clear in the spec. Payloads arriving out of order definitely looks like a bug. Clients need to know what scenarios they need to handle.
- Michael: Is there any benefit for the client to have things come in out of order?
- Michael: as I understand it you might get the deeper object before you get the outer object and then you have to keep hold of that until you can apply it. Is there a benefit to having this on the client? It should be a boon to the client to have stream/defer, but there’s no benefit getting something early if I cannot render it.
- Lee (chat): https://gist.github.com/leebyron/c8bfc0ea70befa851085ee1fe73cbf27
- Rob: there’s definitely a couple different scenarios; what Yaacov was talking about was stream - the ordered list not coming back in index order. There’s also this case that Lee outlined in the gist. There’s also the situation where there’s deferred fragments one within another - should they come back in the order in which they are parsed?
- Lee: if there’s a handful of fields thats only relationship is their parse order then they should be able to come in any order, but if there’s dependencies then the nested defer shouldn’t be returned until the outer defer is.
- Matt: from a client perspective if you gave a path to some inner stuff that hadn’t previously been sent you’d expect to give an error.
- Michael: that’s what I mean - if you have a normalized store then you might not have something to patch it onto, so maybe you have to buffer it until the full thing plays back.
- Lee: I think the nested case is clear here - if you want to not have that dependency then you should structure your query in a different way. More interesting is @stream on a list - can you receive the 3rd item before you receive the second? Thoughts?
- Rob: in that case the path exists, but the client has to handle a sparse list. Seems like you have an array of promises and they’ll each resolve when they’re ready.
- Lee: maybe this is behaviour we should be able to control? Unordered vs ordered delivery.
- Brian: arguments to the field or directives could control that.
- Lee: it feels like a client shouldn’t break if the objects come out of order for @stream. The promises array analogy feels right.
- Matt: I’m 70% certain we enforce that list @stream payloads arrive in order. PageInfo tells you first/last, hasNext, etc. I don’t know how the server/client would work with out of order Connection edges.
- Rob: If you’ve a streamed list with defers within it then the defer on the second item could resolve before the defer on the first item.
- Benjie: Thinking about this from a security perspective, from the perspective of a malicious client, if you can make request values in a list out of order, by requesting far head indices, the server could ask that this is handled in order, as a way to mitigate this sort of attack.
- Matt: it’s reasonable on the server to have a list resolve that returns the list in a different order based on what elements on the list resolved first which wouldn’t break anything if the client can handle the list being effectively unordered.
- Rob: You can always turn an unordered list into an ordered one.
- Lee: to punt on this; how do we restrict it so we can come back to it in future? Have streams require the order of the list be the order that it would have been had it not been streamed (i.e. buffering on the server); the in the future we could introduce an argument to the directive that allows out of order delivery. You can’t go the other way around - we can’t make ordered delivery optional first and then restrict it later.
- Matt: If we establish that the streamed list is ordered, we need to support strict ordering for all older clients.
- Lee: By going from strict to less strict, the client can rely on the stricter behavior, and if we decide to loosen it, clients can decide to support that.
- Lee (chat): https://reactjs.org/docs/concurrent-mode-reference.html#suspenselist
- Lee: there was a parallel discussion when building suspense - how do we show this in the UI as it resolves. Initial take: it just resolves, you show them. There was significant demand to be able to control the render order, so Suspense allows buffering so they get rendered in the order they’re defined. Facebook uses this heavily internally I think.
- Matt: I think you’re right.
- Rob: overall it seems less controversial to store the order. Currently it races the list, but instead it should be more of a tree structure.
- Lee: it’s nice that on the server it’s easier to not buffer so it should be easier - promises would be able to do the buffering for you.
- Benjie: also
for await (... of …) - Rob: I’d like to hear how Michael and any other implementers handle it
- Michael: we’re doing it ordered for both stream/defer because it makes client life easier.
- Lee: takeaways: broad agreement that the spec should say something about delivery order. Tree based approach. Streamed list list order should be preserved, but we should investigate to ensure we’re confident.
- Main aim: to remove message limits (so we don't lose messages)
- Benjie: We’ve had this suggestion many times. I was trying to find something in slack history and it’s gone because it’s from too long ago. Painful. Important discussions tend to happen in GitHub, but sometimes you want to look up something specific in the slack and losing it is painful. People have suggested Discord. ”Discord has brilliant.” Stable, easy to manage, great tools. Discord is growing up, not just for “gamers.” And Discord is putting effort into making the platform more appropriate for this sort of community. Lee doesn’t like the lack of threading. The TypeScript server has cycled chat rooms, where you can trigger a thread. There’s also a bot (Yet Another Discord Bot) and you can create one-off channels for tickets, for instance. Not everyone is a fan of threads anyways. Not losing history is most important to me.
- Lee: I saw it was on the agenda, and I set up a Discord server. The last time I used Discord was when the Reactiflux people set up a Discord, and it was slightly rough around the corners. I’ve been frustrated by Slack’s support of open source communities. Discord has a landing page for open source communities! I’m with Benjie on threads, in that for more casual communities non-threading can be nicer. “I will only lightly mourn the loss of threading.” Loss of history is pretty important.
- Michael: It depends on the amount of traffic.
- Robert: I’m in favour; but there’s a couple caveats: there’s no way to archive automatically message history for a channel, and Slack has much stronger bot integration (this seems to be an ecosystem problem).
- Lee: speculating; I’m hoping that most of the bots that we’d be interested in are built/building as Discord continue to encourage open source projects to use them.
- Michael: How did you manage transitions?
- Benjie: We transitioned from Gitter to Discord, and I just posted in the channels that we’ve moved, whenever someone posts a message
- Michael: Neo4J tried the move, and it seems like 30% Slack 70% Discord, which doesn’t seem ideal.
- Benjie: There seems to be fragmentation even in discords. The solution is don’t reply or engage in retired communities, and redirect them. Though I’m not sure what we’re going to do if we’re “trialling” Discord.
- Michael: Who owns the channels? Can we lock the channels?
- Lee: We should trial run it for a month or so. Don’t just let it sit, but really try. I’ve pinned a couple messages in the Slack. I’ve already created a couple channels which mirror the important ones in Slack.
- Brian: I’ve setup discord.graphql.org which redirects; LetsEncrypt might take a while to make the SSL. Other groups that have done this have exported the entire message history and then archived that. It doesn’t export the private chats (DMs, private slack rooms) but it at least keeps an indexable record about what the project has been talking about.
- Benjie: The discord open source program allows for vanity URLs.
- ACTION - Lee: hook Benjie up with permissions
- ACTION - Benjie: help get vanity URL, etc.
- Uri: the Guild has a popular discord channel, and we modeled the channels on being general GraphQL. We have no business being the official GraphQL discord and the Guild is happy to hand it over to the GraphQL foundation.
- Benjie: We need to figure out the scope of the chat server. Are we going to talk about GraphQL foundation matters, or are we talking about each individual project and meetups and things like that.
- Lee: The existing Slack is a free-for-all. Anyone can join, anyone can participate. As long as people are abiding by the code of conduct we should be in good shape.
- Benjie: sounds good.
- Lee: Benjie I’ve given you some permissions - let me know what’s involved.
- Lee: Uri I think I agree it makes sense to have one unified place. Not sure what that’ll involve but we’ll get there.
- On behalf of Ivan
- Spec: Forbid duplicating argument names graphql-spec#877
- graphql-js: Add 'UniqueArgumentDefinitionNamesRule' validation rule graphql-js#3208
- Benjie: I’m Ivan for today! He couldn’t make it to the meeting. He asked me to champion this for him. This work has been going on for a while. This comes up in many meetings. Ivan wrote up the spec changes that are required for this RFC. We don’t have a rule in the spec that says arguments have to be unique. I’ve looked over the spec and it’s a very small change, which adds a constraint in three places. My job is to advance this to the next stage. It’s a late addition to the agenda.
- Lee: Unless there’s any opposition I’m going to make this a RFC 1 proposal and we can all agree this is a thing worth pursuing.
- Lee: In the last couple of hours, Ivan seems to have put some links up for review already.
- Lee: RFC 1
- ACTION - everyone - review on the spec text and the changes.
- Lee: hopefully we can advance this pretty quickly.
- Lee: theoretically it’s possible that this might break a query; it’s possible that someone has typo’d this in a way that we want to prevent and will find that their query is now invalid.
- Matt: “If it’s possible to abuse the spec, someone has found a way to abuse the spec.”
- Michael: what about the May spec release?
- Brian: that vote is active so if you’re on the TSC check your email.
- Michael: is there a deadline for the vote?
- Brian: it has to be open for at least a week but if we hit the threshold we can close it early. I think it’s a majority vote (will have to check), but it does not have to be unanimous.
- Brian: TSC members: ...
- Lee (chat): https://github.com/graphql/graphql-wg/blob/main/GraphQL-TSC.md
- Apollo for the second half of the year need to figure out what to do for subscriptions. Uri helped? Subscriptions-transport-ws. At some point it fell out of maintenance. There’s a fork of it by a community member [Denis Enjo] that’s becoming really popular. (Websockets / subscriptions.) Does the GraphQL WG have a role in the protocol?
- Michael: there’s an RFC on the GraphQL-over-HTTP repo relating to adopting it.
- Brian: there were some protocol changes versus the Apollo version.
- Michael (chat): graphql/graphql-over-http#140
- Michael: JS adoption is exploding, and it’s very active.
- Brian: is this going to be GraphQL-over-WS or part of GraphQL-over-HTTP?
- Michael: we support both based on the subprotocol.
- Benjie: we do the same in PostGraphile - supporting both protocols.
- Michael: it would be good to specify this as part of the GraphQL-over-HTTP spec.
- Michael: over HTTP now is covering websockets but also incremental delivery so it’s not necessarily just simple HTTP any more.
- Benjie: definitely chat to Denis and also have a look at the older Working Group recordings because Denis talked about the differences and why they exist.