Skip to content

Latest commit

 

History

History
64 lines (46 loc) · 3.55 KB

2018-05-24.md

File metadata and controls

64 lines (46 loc) · 3.55 KB
Raw

GraphQL WG Meeting #5 Notes (May 24, 2018)

Agenda

Last session recap:

Next upcoming session GraphQL (day before GraphQL Europe conference, possibly 3-5pm local time) Johannes Schickling to find space Lee Byron to ping regulars

Dates for upcoming sessions:

  • 09-20-2018, 11-08-2018 Lee Byron to build empty agendas in graphql-wg
  • Cadence: 6-8 weeks for 2-3 hours.

Updates from Lee Byron:

  • Academic citation tool for people to formally quote the spec. Release by the end of the week?
  • Release notes, needs help on compiling the list of things that changed in the spec. Release notes to be created as a draft first, to be added for next week. MP, OL, JS to help LB. We can use it as an opportunity to treat it as a PR event, coordinate the implementations around blog/posts and tweets announcing it.

Agenda Items

“Directives Are Unique Per Location" validation, #429:

  • Biggest motivation is to split up the schema. By having the directive used multiple times on the same field we can leverage type extensions to achieve that.
  • 3 possible solutions laid out in #429.
  • Should this new rule apply to both query and schema definition? Applying it to only schema could lead to implementation/confusion errors.
  • All possible solutions seem viable, none preferred yet.

Seems like this is worth moving forward on. The biggest concerns are

  • where do we split behavior (SDL vs. queries)
  • implementations will need to change from a map<dir_name, dir> to map<dir_name, dir[]>

There is currently no standard error messages in the spec the implementations can reliably use:

(graphql CATS) Common testing framework to test how spec compliant a given implementation is: CATS is to be run against library implementations not a production GraphQL server.

Thoughts:

  • Error codes/ identifiers for rules (Rules have multiple components, so an id per rule wouldn’t be granular enough)
  • Identifying substring?
  • There should be a programmatic way to understand the test results
  • We can add testing specification to CATS and later add it to the spec if needed

Proposed solution: Have CATS introduce some concept of a mapping, that maps from implementation specific errors to GraphQL spec errors. Each implementation can contribute to CATS by adding the list of error messages for each spec rule component. OL will open a new issue on CATS to show how this would work + examples

Transport level batching (Executing multiple operations in a single request)

Thoughts:

  • Batch support was added to Relay. Place to start with, things needed:

    • List of operations & variables
    • Number of times to run each operation (with potentially different variables)
    • Dependency between operations (if any)

  • You can achieve primitive batching with aliasing, though operation dependency and executing both mutation and query wouldn't be possible with aliasing alone.

  • BB to look at championing batch support

  • @defer first class support, like @skip and @include? Batch wasn’t a priority for LB.

    • Sangria has batch support through export feature.
    • @defer was implemented in graphql-java

Closing thoughts

  • Open source Facebook fund for GraphQL? The whole ecosystem could benefit from such a fund. Lee Byron to reach out to Facebook.
  • Find ways to level GraphQL ecosystem across languages.

Next agendas ideas:

  • Map types? (find champions for new ideas and proposal to the spec)