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)
- Review draft TSC policies and procedures (15m, Lee/Brian)
- Schema Coordinates RFC check in (15m, Mark)
@defer/@stream(15m, Rob)- Experimental graphql-js published
- express-graphql PR
- Mark
- Benjie
- Lee: #517 was closed last meeting
- There are some open ones still.
- Evan: there are a few on my plate I haven’t gotten to yet
- https://github.com/graphql/graphql-wg/blob/master/GraphQL-TSC.md
- Brian: Fairly typical for linux foundation projects
- Formal technical governance for technical decisions if there’s a need for a vote
- Goal is to be fairly light-weight, with few exceptions the process of spec changes and contributions remain the same as it was
- By and large aim for consensus, votes and the official voting members are mostly a fallback.
- TSC meetings will be held at the beginning of the working group calls each month.
- Lee chose the initial slate to bootstrap and avoid an initial big dramatic voting process for the new body. Voting starts next year.
- The Specification Membership Agreement is the only part that’s really written in stone, the rest is designed to be adaptable.
- Lee: Personal motivation is to scale myself, since my bandwidth is limited, so that final calls can be made by other people.
- Editorial changes can just be merged to the doc, meaningful changes should follow the process designed.
- Discussing at the working group is the normal process already anyway.
- Requested approvals feature in GitHub will be useful to flag others from the TSC to approve things.
- Mark: as a reminder, the elevator pitch: in various GraphQL projects we need to refer to components of the schema, e.g. field name on a type, we commonly write this as e.g.
User.name. There's no official convention, but tooling uses this convention, so this RFC tries to standardize and extend this syntax (e.g. referring to arguments) - Great reviews so far, especially from Ivan
- What's the next steps?
- Lee: ACTION - everyone: take a look at the appendix and reply with detailed feedback
- We should split this; RFC to document the process (since we can merge RFC changes frequently), and separate PR with the Appendix
- Some things might be able to be simplified, e.g. how do you differentiate between Type, Union and Interface types, seems like they might all be the same from this point of view.
- Really happy that for all options there's an example. Really nice.
- When selecting an argument, how do you feel about trailing a colon after the argument name
- Benjie: I like it, it's from Obj-C?
- Matt: it also makes it closer to what you'd write in a document
- James: it makes it very clear it's not executable - this is the argument, not the input
- Ivan: I think it'll help when finding fields with arguments e.g. with a selector
- Matt: lets us specify a field that requires multiple arguments, e.g. referring to a field that has both a "width" and a "height" argument
- Lee: good point
- Matt: when I respond to support requests, I often have to tell people to provide both arguments to a field. Currently arguments are an end state:
Type.field(argument:)there might be a situation where we refer to a field that has multiple arguments. - Mark: schemas don't allow overloading field names, so I don't quite follow
- Matt: for this spec for referring to arguments in the schema this makes sense; but if we put it in the spec people are going to start using it in interesting ways, so allowing for more flexibility here may be good.
- Mark: the intent of this proposal is to select very specifically one field/argument/element from the schema.
- Evan: we use lots of dots, rather than parenthesis.
- Matt: for only referencing the schema this makes sense.
- Lee (chat):
- Found what I was thinking about:
- https://docs.swift.org/swift-book/LanguageGuide/Functions.html
greet(person:)
- Lee: Mark, it makes sense to limit the scope, absolutely. What Matt is suggesting is that people may want to expand this syntax in the future, so we should try and make sure it's not limiting.
- Matt: I was excited when Lee proposed the colon because it allows a change in the future, not that we should make the change now.
- Evan: for fields on an input object:
InputObject.field; but what do we do if we want to refer to nested fields in a mutation? - Evan (chat):
- type Foo { field(bar: Bar) }
- input Bar { baz: String }
- Foo.field.bar.baz <- ?
- Mark: is Bar.baz enough?
- Evan: it's enough to refer to that field, but not the usage of that field.
- Ivan (chat):
- Foo.field(bar: Bar.baz)
- Lee (chat):
- Within existing proposal, two coordinates to point to this: Foo.field(bar:) Bar.baz
- Benjie (chat):
- Foo.field(bar:->baz)
- Matt: this relates more to field path than allowing you to dive into arguments
- Lee: Bar.baz is the shortest path; but it loses information about how did you reach that field. We could give you many schema coordinates. Matt makes the point there are a set of things people want to do other than reference a specific thing in the schema: querying the schema with selectors, walking through the path to a field, etc. Keeping it limited now is wise, but we should consider what we might want to do in the future to make sure we leave ourselves design space to handle these other problems.
- Mark: one aim is to have a [one to one mapping from schema coordinates to an entity in the schema].
- Lee: ACTION - Evan, Matt, and everyone else: go into this PR and flesh out the details. Comment on how we might extend the syntax.
- Rob: Ivan's published an experimental release of GraphQL.js and hopefully express-graphql is coming soon.
- I'm working on some implementation detail feedback currently.
- We're blocked on the TypeScript migration of GraphQL.js, but hopefully we can now get the feedback we need.
- Michel: we've implemented it in Hot Chocolate and plan to ship it next week.
- Rob: Defer and Stream?
- Michel: we're still working on Stream, but Defer is working fine.
- Rob: I've heard people experimenting with this 👍
- Ivan suggested that I write a blog post to get more attention; I've drafted that: https://docs.google.com/document/d/1QITARWWfLDhEnT0tpfkVZeyloXyQMSIWArBaQbT63kI/edit#heading=h.gv8rd31catco
- Do you want to publish it on the GraphQL foundation website, or...?
- I'm going to present it at some GraphQL meetups.
- Lee: great.
- Michel: we have it working in our editor and it's really nice using it end-to-end.
- Rob: I also got some spec feedback from Benjie that I'm working on.
- Lee: mention this to Uri, Uri is working on our newsletter. If you record a meetup talk, Uri can help you spread that.
- Michel: it's much easier to use than batching, much more natural to put a defer directive.
- Lee: great there's positive feedback. Is there anything you need on the Express GraphQL PR?
- Rob: Ivan's going to publish an experimental package
- Ivan: for every official release we'll have an experimental release attached to it. In your package.json you just add
-experimentalor.experimental(see the README) - In the next couple days (possibly tomorrow) I'll push out a new release.
- Lee: I like that there's constant iterative progress here. Great work.
- Lee: having an implementation out is the qualifier for stage 2, so we're almost there.
- Michel: is there any progress on @live? Is it dropped? Did Facebook ever get it working?
- Rob: I've personally not worked on live at all.
- Lee: Matt and Jafar may have more ideas.
- Matt: defer/stream are very actively used. Very common tools for people at Facebook. @live is also a fairly actively used tool, but the server-side complications and implications of live don't work on all kinds of servers which stream/defer work basically everywhere.
- Michel: you need a reactive datastore?
- Matt: yes, exactly
- Jafar: there's been some evolution; a big change is that we were taking a reactive approach on the server, but we've moved about this. Now live queries are moving towards more of a subscriptions model. Value props: 1. DX on client, 2. DX on server (not having to explicitly trigger things, having a reactive data store). The latter has failed, the former is still an open question. We're still very much in the iteration phase here, it's too early for an RFC.
- Matt: agree. Because Facebook has more years of tech debt in GraphQL, we still have situations that the OSS community would never face because of the legacy syntax GraphQL used to have. The broader community should also be iterating on something in this space.
- Michel: good to hear it's not dead!
- Jafar: there's some things that are hard to make live, e.g. connections. Inconclusive at this point.
- Lee: last time I was involved, is @live a property of the query or of something within the query? @defer/@stream has resolved this.
- Jafar: we have fully live queries; we want to decouple the what and the how. GraphQL explains the what, we've been configuring and subconfiguring the how. E.g. I might want different freshness guarantees for different fragments. We've not made as much progress as we want to. It's a hard problem and our aspirations are to continue pushing but it's slow going.
- Mark: process; there's GraphQL.org/blog, but it's not very discoverable. Are we fixing this?
- Lee: great question. Uri's moving the site to use Gatsby, but the blog got missed. The blog's currently deprecated, but we don't want to remove the content that's there. Uri's looking into other things we might want to do to spread information. If anyone wants to resurrect that, do a Uri and help out!
- Ivan: we have a second blog on the GraphQL foundation; we use it for summer of code and season of docs. I want to give it more visibility. We have content for a blog. Blog would be useful, not as opinion piece, but as announcements.
- Lee: channel this feedback to Uri, he's owning this marketing problem, and Orta's helping him out a lot. Feel free to let Uri know you're interested in helping.
- Mark: I might reach out to Uri about that.
- Benjie: can we add people's GitHub username to the agenda template to make it easier to tag in action items?
- Lee: love that idea; I'll get on it
- ACTION - Lee: update the agendas to recommend adding GitHub username, and to add yours to the attendees table.