Skip to content

Latest commit

 

History

History
81 lines (76 loc) · 6.2 KB

2017-08-14.md

File metadata and controls

81 lines (76 loc) · 6.2 KB

GraphQL WG Meeting #1 Notes (August 14, 2017)

Agenda

Attendees

Name Organization Location
Lee Byron Facebook Menlo Park, CA
Greg Hurrell Facebook Menlo Park, CA
Angel Gomez Facebook Menlo Park, CA
Johannes Schickling Graphcool Berlin, Germany
Ivan Goncharov APIs.guru Lviv, Ukraine
Sashko Stubailo Apollo San Francisco, CA
Oleg Ilyenko Sangria Berlin, Germany
Andi Marek graphql-java Germany
Robert Zhu Facebook Boston, MA
Tim Ryan Facebook Boston, MA
James Baxley Apollo Anderson, SC
Dan Schafer Facebook Menlo Park, CA
Martijn Walraven Apollo Amsterdam, The Netherlands
Ian MacLeod Convoy Seattle, WA
Robert Mosolgo graphql-ruby Charlottesville, VA
Thea Lamkin Apollo San Fancisco, CA

Agenda

Discuss upcoming meeting schedule

  • Johannes mentioned that it would be nice to have a time shift for the next meeting because he's going to Australia.

GCL: GraphQL Configuration Language

  • Johannes presented a proposal for a common GraphQL Configuration Language (GCL).
  • GCL is intended to be a type-safe alternative to JSON, YAML, etc. based on the input type syntax of GraphQL
  • It uses the .gcl extension.
  • Advantages of utilizing GCL are that it would use a common language and could therefore piggyback off of existing GraphQL tooling and provide a better developer experience.
  • An example of this configuration file set up as a DSL for Docker images is included on the graphcool github (Docker configs are only one of the several use cases for this).
  • Johannes would ideally work with Hyo from the GraphQL core team on getting this supported in existing tooling.
  • A few concerns that were brought up are:
    • How would this handle scenarios where there is more than one type of configuration?
    • This seems like it has a lot of overlap with other sorts of configuration languages.
  • The general consensus was that since this is not encumbering the language in anyway and brings something of value more exploration should be done such as for a Docker compose file or a VM deploy to Digital Ocean, etc.

Status Update on Subscriptions error-handling

  • There should be a way to allow callers to distinguish between initialization and publish errors when calling subscribe.
  • The proposed behavior is the following:
    • If the operation is successful, return an AsyncIterator representing the response stream.
    • If the operation failed with an informative error for the client, return an ExecutionResult with an errors field but no value field.
    • If the operation failed due to a system related problem, such as an unavailable pubsub, system, an error will be thrown.
  • This change would make the reference implementation match the spec more closely.
  • The PR for this proposal has since been merged into graphql-js

"Verbatim string" literals and schema descriptions

  • Proposal adds a new lexed token, a long form text or verbatim string, similar to that found in Python and Scala.
  • A multiline string would start and end with triple quotes.
  • Especially useful for example for people wanting to comment schema definition files by hand.
  • The proposal mentioned using """ to enclose these verbatim strings,
  • Quote literals become part of the spec so they should be included when parsed into ASTs vs comments which are usually stripped.
  • The general consensus was that minimum common shared indentation should be stripped as to make reading and writing as simple as possible.
  • Verbatim strings should have as few escape sequences as possible to avoid surprises.
  • Special care needs to be taken so as not to break existing

Standardizing unique IDs in the spec/tooling

  • GraphQL currently doesn't have a standard way to implement unique identifiers.
  • Not having this currently impairs the ability to create tooling that processes results without involving configuration for how people use IDs.
  • It would provide a standard way to handle things such as cache invalidation.
  • Should probably be nullable since it is not always going to be provided.
  • There should ideally be a way to specify in what context the ID is unique.
  • This should be done in a way that is as non breaking as possible and doesn't require people to change their current setup.
  • Ideally it would leverage type ID.
  • It was mostly agreed that this would be valuable and followup for this would be to resurrect Sashko's stale PR and follow up discussion there.

Define process for the changes to the specification

  • As of now there's no clearly defined process that indicates what stages PR's are at leading to confusion.
  • Sometimes the authors of PR's don't get a clear picture of what's blocking their acceptance or what the followup should be: Is it ready to be merged into the spec? Is it safe to start adding this proposed functionality to tools? Should I expect major changes to this PR? Is this important to GraphQL?
  • It was proposed that there should be a stage setup similar to the one in TC39 (Proposal/Champion/Stage)
  • Explore the possibility of having a bot that automatically pings key stakeholders if a proposal isn't commented in a certain amount of days.
  • There was a general consensus that this would be something valuable to add with the following observations:
    • Make the stages a general criteria instead of a set of fixed rules.
    • Have a predictable timeline of when things are going to be merged so that stakeholders and users are aware.
    • Explicitly alert everybody of when proposals are going to be merged into the spec.

GraphQL Configuration for cross-tool usage.

  • Discussed how we could lower the barrier of entry for people attempting to build gateway services allowing for some sort of schema federation.

Meta: How has this meeting worked today?

  • It is good to have a set of defined goals for each agenda item.
  • Opening PRs and issues is a good place to have followup discussions to things talked about in the meetings.