-
Review current Draft for ["Stages for changes to the GraphQL Specification"]
-
Provides greater visibility to what is happening
-
Clarity on how to get something into the spec / how to start
-
Unlike TC-39, stages start at -2
-
Not sure if ideal to have lockstep between spec and graphql-js
-
JavaScript stages have been successful because of the babel transforms
- Can use next stage ideas early (JavaScript)
- Is is possible to add to the library under a flag?
-
Want to allow for experimentation with the language
-
May be valuable for a global test suite to verify spec
-
- Lack of error codes makes it hard to validate implementation
- How can we assert on different error solutions
- Having official return value for validation failure / prescribed errors
- Follow up on errors in later agenda item
-
Negative numbers may make it hard to determine when an item is officially in a proposal status
-
Documentation of process is easier to adopt for community
-
Living document
-
Would be valuable to have a proposal list
- Stage sorted and possible implementation examples
- Possible process for Champion identification and re championing it
-
Versioning the spec makes it easier to determine what level of support servers implement
- Version is be the release date
- Already in practice with spec website
- What does semver / major + minor change versions look like?
- A lot more ambiguous
- Small for one could be large for another tool
- Probably not a good idea for spec
-
Very little potential difference between stage 3 changes and the formal spec
- Having a regular schedule is important
- Some implementors won’t implement “working” spec features, only official spec
-
Spec should be trailing indicator of libraries
-
Need to add feature grid and formally recommend stage 3 as part of the implementation spec
-
Not it is most useful to provide explanation of process and even add labels of status
-
Discuss status of IDL specification
-
Not a lot has happened from the last meeting
-
Feedback on both spec and implementation need to be followed up on
-
Want to get in before cutting the 2017 additions
-
SDL is an IDL, so both terms are valid
-
SDL is the recommended approach
-
Champion? Lee?
-
Status of Scalar serialize as built-in scalar type RFC
-
Need a clear champion
-
Clear path forward through stages and just be picked back up
-
Let’s use the current stage process outlined above as a test case
-
Discuss interest in and possible scope of defining a more structured format for errors
-
Useful for client usage
-
Graphcool has done this well
-
Distinction between validation and parsing errors
-
Agreeing on execution error tagging
-
Want to be able to return an error and a fallback value
- May need to be an additional discussion
- A try / catch implementation
-
General agreement on value of returning error and value
-
Not sure of high confidence of internal Facebook’s error handling to use as spec
-
What are the most important problems to solve first?
-
Multiple small proposals
-
Do we want to “require” error process in favor of predictability over flexibility
- In the very least validation vs parsing errors
- Word it as “may” in the spec to encourage, but not require
- Could provide value for common implementations that aren’t required (optional spec)
-
If we have a CATS style validation process that could include optional errors
-
Improving structure would be valuable
-
Call out the flexibility of the current errors spec
-
Would be great to know usage patterns at Facebook
- Also collect external information
-
Martijn as champion of this process
- Initial proposal
- Further use cases
-
Extend the errors into the type system
- SDL defined errors
-
Possibly two proposals?
- Common fields
- Long term solution / error type system
-
Typed errors are more indicative of language usage
- Reuse __typename?
- Extend introspection into error documentation
- Could use a fragment against an error to pull back certain types?
- Or should we return all fields since they are typically out of bounds?
-
Update on community projects around schema stitching (Namespacing item moved here)
-
Project list as of now:
- Graphql-tools (schema stitching) (JS)
- Merge (declaratively) / call (imperatively) others
- GraphQL weaver (JS)
- GraphQL Join
- GRAMPS (slightly different in more for modular driven schemas)
- Internal usage at some companies does like items
- Graphql-tools (schema stitching) (JS)
-
Language independent merging
-
What spec changes would / could be needed to improve this?
- What makes it easier to fit together?
- We may not need any changes?
- Not sold on namespaces (Sashko + Lee)
- Don’t want to push namespace to clients to have to deal with it
- Possibly just an ergonomics change (underscore vs
:) - GraphQL is commonly used as a codegen tool for many places so codegen is possible
- Haven’t run into the issues initially thought so may not require anything
- Keep an eye on the space
- Need more experimentation in companies needing it
- No need for champion / spec work now
-
Could the schema expose additional meta information?
- Directives
- Exposing a hash of a schema?
- To determine schema version / changes
- Test out new ideas and report back
-
META
- Create possible spec addition repo format like TC-39 repos
-
Discuss next steps for "Standardizing unique IDs in the spec/tooling"
-
What is the smallest first step here?
-
Sashko as champion
-
“If you want ids, call them X and they need Y”
-
Going to move forward with new repo, split and move issues, update proposal
-
"GraphQL over HTTP" specification
-
There is a general consensus
- Using POST
-
Could help for using things like Apollo Link outside of Apollo
-
Standardization around tooling would be valuable
-
Ivan is champion
-
Discuss upcoming meeting schedule
-
3 month cadence is ideal
-
December 8th is current planned date