Skip to content

Latest commit

 

History

History
162 lines (128 loc) · 10.3 KB

2018-11-06.md

File metadata and controls

162 lines (128 loc) · 10.3 KB
Raw

GraphQL WG Meeting #8

Future WG meeting date proposals (10m)

  • A proposal was made for a 6 week working group cadence, to be adjusted if there are holidays or other conflicts.
  • Concern raised about hecticness of coordinating with other events (GraphQL Europe, GraphQL summit, etc)
  • No dates currently decided, Lee will post some candidate dates for discussion on the ?graphqlwg repo?
  • Day of week: midweek
  • Time of day: 12-3pm PST

GraphQL Foundation (Updates & Discussion (10m)

  • Press Release: https://www.linuxfoundation.org/press-release/2018/11/intent_to_form_graphql/
  • Call for anyone who is interested to get involved and participate
  • Foundation will aid with RFC processes, resources, etc.
  • Does the scope of the foundation overlap or extend WG?
    • Scope is spec, ref impl, graphiql, and component parts of that gql lang svc.
  • Does that include graphql-cats?
    • Could, but not part of the plan. Currently just part of transfer of ownership.
    • Good contender.
  • Similar adoptions by Linux Foundation? Node.js foundation and CNCF, Swagger, OpenAPI
  • Are there “permanent seats” as part of Linux Foundation? Does it require donating money?
    • Technical committee will be completely open and not require financial contribution. Also for contributing to projects
    • New steering committee will figure out how to do additional things (such as marketing, technical docs, host meetups, etc). This currently haphazardly organized by volunteers, but the foundation will help with more organization of this

Briefing on ISO GQL (SQL for Graphs) (5m)

  • Neo4j uses a query language called Cypher (pattern matching) and is working with other vendors to standardize graph query language. Currently called GQL
  • ISO working group to standardize GQL and how it interacts with other languages
  • How can graphql community be helpful to this effort? Is there an overlap? (Lee)
    • Technical level - no overlap
    • GQL name is potentially confusing for users as GQL is used to refer to GraphQL (also Google Query Language)
  • What is best way to contact ISO GQL group?
  • Is there a precedent for GraphQL database integrations as part of working group, or is this beyond scope of working group? (Will)
    • Lee: no plan for it, but feel free to pursue if community is interested
  • Could a standard set of directives be used to define schema mappings, etc?
    • Standardization should be used when many different reasonable solutions have solved same problem and unification would help reduce noise/surface area

graphql-cats adoption issues (5m)

  • Working on Gqlgen - code generation based GraphQL Framework for Go
  • 2 issues
    • Reference implementation is not using it - is it testing the right things?
    • Directive based - hard to implement in codegen
  • Who’s using it? Scala, sangria (??)
  • Other languages are using the GraphQL.js reference implementation tests; works well for parsing and validation but cannot be used to test execution for other language implementations
  • Would be useful for benchmarking?
    • This would increase the scope of the project
    • Could be harmful - benchmark results might not be meaningful
  • GraphQL JS opportunity to implement graphql-cats driver
  • Error codes! Still not standardized, still an obstacle. Would be great if that problem could be addressed independently.

**Interface inheritance **(10m) RFC, reference implementation <- needs more eyes

Discussion of Deprecation Directive Additions (5m)

  • Kevin (champion) not present.
  • Ivan addressing
  • Why not available for input fields? Possibly oversight! Started with fields, extended to enums when it needed to happen. It just hadn’t arisen yet, by the sound of it. Just needed a concrete reason.
  • This would match the way Fields, types & enums.
  • Missing graphql-js edits right now, could be fast tracked through drafts offline.
  • Progressing to Stage 1
  • Follow-up with graphql-js ref implementation

Continued discussion on input unions, RFC (10m)

  • Tim, showing presentation screenshare:
  • Alternative solutions:
    • Adding literal type
      • Doesn’t provide much value over __inputname
      • Adds complexity in the form of a new type or syntax, same as to inputunion
      • Effectively adding metadata in the same fashion
    • resolveType
      • Essentially similar to how it works for unions
      • Issue is that it’s not really the mirror of unions because @ runtime client wouldn’t know the type until the server processes it. IF you pass extra data that resolves to this type, does ??
    • Type first coercion
      • breaks down with larger gen’d schemas. Would break down when the ordering of the types matters in the spec.
      • Issues in structural vs nominal typing
      • Confuses type shape with type use / intention
    • __inputname
      • Has the overhead of adding a new syntax
      • Simplifies by stripping need for metadata from input shapes
      • Scales to many input types without worrying about overlapping fields
    • New Relic Use Cases
      • GH issue best illustration (PR395)
      • By specifying __inputname you’re simplifying by more easily matching input with output.
      • __inputname on the server
        • Destructuring allows you to find the input you’re working with.
        • With typegen you can avoid the need to use info
    • Lee: How would an input union include a scalar?
      • If scalar is predef’d : String Float, use a Value property
      • Downside of wrapping a scalar in an input (??)
    • Ex: If you have date or string, how do you know what it is?
    • Benjie: Don’t like the idea of using input unions to combine input with scalars.
      • If you were to combine scalars, the only way they could see it working is if you only had ??
    • Tim agrees with Benjie
    • Output type system is nominal, input type system is structural
    • Oleg Q about struct type. No type def on input type?
      • Cares about composition of input object types
      • Believes that composition of scalar and input object types is only syntax sugar
    • Lee: Can always use a wrapped tag union
    • Tim: You’d have to use a wrapping object that has a field for every potential type you’re going to wrap and has different field names for those.
    • Matt: On the server side that’s essentially the same as switching on __inputname. Is syntactic sugar.
    • Lee: If we want to go for the predetermined name, match naming consistency, __typename
      • Allowing API designers to specify what those are is maybe ideal.
      • This introduces input unions, AND a nominal typing layer over an existing structural input system .
      • Other ways to do tagged type discrim without requiring the layering of another nominal typing layer on top.
    • Matt: When you first define your input type, you will have to make __inputname a required field from the get-go.
    • Tim: Wouldn’t have to be defined on the type, it would just be the type name
    • Matt: Ex.: for an input (old client) that has no inputname because it’s not a required field, hits the server, al
    • Tim: would have to define up front if you’re using the input type, or the input type union. That difference would change the necessitation.
    • Benjie: Alternative: Mark one type as a default. (! or default k/w). Allows something to address legacy clients on old input types as a non-breaking change.
    • Adam: Would also let you support scalars if that scalar was the default in that union?
    • Benjie: Not necessarily if there are multiple, but if one, potentially.
    • Tim: Is making migration without a breaking change a goal?
    • Benjie: ~, Lee: Nice to have, not a blocker.
    • …
    • Lee: Wrap up, concrete next steps — 
      • Passing a variable where variable has specific input type, then passing that var in where it expects a input union to be. The inputname field is checked at the variables coercion rather than the input unions coercion. Bunch of input coercion changes that need to change. Avoid predetermined type discrim., only implement when necessary, provide room for API implementor to do itself. Not right for gql to have default, potentially awk in an API.
    • Tim: On union you have to “spread … on”
    • Ivan: short note about prev exp with open api. Same problem on swagger. In their case, where you can define new field on payload which requires description, added in 2.2 without implementing it anywhere so it’s totally broken and documentation engine was only tool which correctly implemented it. Spent a lot of time working on a specific issue because of large number of edge cases.
    • Tim has enough feedback to move forward.

Update on #429 - limiting the scope of "Directives Are Unique Per Location" validation. (OI 10m)

  • #470 - [RFC] "Directive order is significant" section
    • Looking for guidance - no changes to graphql.js or sangria — can merge?
    • Might currently be a map, but should be an implementation detail.
    • Accepted, work on merging it.
  • #472 - [RFC] Limit directive uniqueness to explicitly marked directives
    • Repeatable
    • In a state where it can move from draft to proposal.
    • Looks good, Matt has Qs about naming on the AST, but happy to have on graphql-js now.
    • Ivan: Need more examples and qualification. Everything is described and valid, but re: design principle: Directives should be applied in some order, it would be good to have an example for why it’s important. 2nd: you can extend and duplicate with extend.
      • One potential issue: Make new introspection query incompatible with old servers. Doesn’t think we should bother adding isrepeatable in graphiql and other tools until we figure out how to do the same introspection.
    • Next steps: get PR in shape to land
    • Moves to Draft.
  • graphql-js #1541 - [RFC] Added support for repeatable directives (also added an implementation in Sangria)