- [Lee] Write up a draft plan for freeze and release
- [Lee] Add a non-normative note to explain why variables cannot be self-referential
- [Rob Z] Move Lexer Lookaheads to stage 3
- [Victor] Re-frame empty composite types proposal in terms of the specific problem rather than expressing all the problems that it could potentially solve.
- [Lee] Grant website access to Tanay and Orta
- [Lee] Give detailed feedback on website code page
- [Mike, Ivan] Alpha version of interfaces implementing interfaces
- [James] Concrete examples of interfaces implementing interfaces implementation complexity
- [Mike] Ensure that test cases are present for interfaces implementing interfaces
- [Everyone interested in input unions] Contribute to the Input Union RFC document before the next meeting to make requirements/tradeoffs clearer
- [Ivan] Write proposal for how graphQL cats can be integrated into graphql-js
- Still keen
- Not sure where to store the ideas/proposals document
- Graphql-js for now, move it later
- [Lee] Every agenda item should have a link (e.g. RFC, PR). Add this requirement to the agenda template.
- [Lee] ✅
- [Lee] Open issue on github to discuss meeting time
- Will do so in future, sorry forgot this time.
- [Mike] Publish a post about interface implementation
- Mostly written, awaiting for release to be cut to avoid breaking changes.
- Lee: call this closed then
- [Lee] Sync with James B (Apollo) on interface implementation
- Didn’t manage to address this
- [Mike] Move interface proposal to Stage 2
- Completed in working group repo/spec repo
- [Vince] Summarize input union problem statement with concrete examples
- Lots of activity, statements and examples
- Done
- [Vince] Create a new issue for input unions
- Done
- [Lee] Close outstanding input union issues and link to new one
- Will revisit later today
- [Matt] Sync with team about Facebook Identity and figure out what we want to put up.
- Sync’d with Identity and Relay; it seems this may come out with future versions of Relay itself - so likely this is where that will end up
- [Lee] we will just stay tuned
- [Lee] Post time suggestions for next meeting
- (Duplicate of above “Open issue on github to discuss meeting time”)
- [Lee] 6 months is too frequent, 16+ months is too infrequent. Would like to shorten. Three options:
- Annual like TC39 (?)
- 6-month cadence
- Cut it when it’s ready
- [Gabriel] Time window instead of designated release date
- [Benjie] Once a year, but time within year is flexible
- [Benedikt] Need a freeze period where only fixes are applied
- [Lee] I will formalize an editing window before release
- [Craig S] Annualised cadence seems wise
- [Michael Paris] This works well
- [Matt Gadda] Freeze period gives maintainers time to prepare
- [Michael Staib] Hot Chocolate implements spec features once they hit draft
- [Lee] Tactically, for this release… If we want to follow Rust’s model of one exciting release per year, makes sense to “frame” our releases around the year - so release the 2020 (current) in January?
- [Ivan] Suggest aiming for Spring. Ready for conference season. Feature freeze from January.
- [Lee] I’d like to avoid the freeze window being too long - encourage early feedback. Probably a couple weeks, probably not months.
- Probably freeze in december for January release
- [Action - Lee] Write up a draft plan for freeze and release
- [Benedikt] Input objects may reference other input objects, even themselves. This RFC ensures that you cannot describe a chain of input object types that is non-nullable. It becomes an unusable (input object) type.
- [James] The spec is currently ambiguous about circular relationships in general
- [Ivan] Issue is that variables can have recursive references, JSON cannot but YAML could, but there’s no way of expressing recursive objects in the GraphQL query language itself.
- [Lee] Is this a real problem that causes pain? Is it a theoretical problem that deserves solving?
- [Craig] Allowed in new versions of typescript. Would disallowing in GraphQL be a functional drawback?
- [Benedikt] I ran into this - inadvertently made a schema unusable. Static validation would be nice.
- [Mike M] Is this a refinement that we could add now and remove later if necessary?
- [Lee] Something to keep in mind is that this RFC is specifically in regard to recursion in input objects, not a general approach to dealing with recursion.
- [Mike M] It’s possible to pass a self-referential input as a variable assuming that we use a capable serialization format (not json).
- [Ashi] A self-referential type can’t be expressed as a literal, so it wouldn’t be possible to provide a default value
- [Lee] [Action - Lee] Add a non-normative note to explain why variables cannot be self-referential
- [Lee] Early detection of recursion. Concerns of additional complexity to the spec.
- [Rob Z] This is not an issue for AWS Appsync
- No other complaints
- [Rob Z] [Action - Rob Z] Let’s move to stage 3
- [Ivan] You can apply the same directive on the same field multiple times, but you need to mark the additional directives as repeatable
- [Michael Staib] We are already using repeatable directives for a while now. Can be useful for stitching together multiple GraphQL interfaces. It is a great benefit to have this feature.
- [Michael Paris] Amplify also uses repeatable directives, for similar reasons as Staib brought up. One example is the key directive to configure the primary and secondary keys.
- [Ivan] If there aren’t any changes needed, let’s move to Stage 3, resolve any conflicts , and merge as-is.
- [Lee] Ok to move to stage three outside context of this meeting
- [Victor] Updated based on feedback from Lee - addressing use-cases individually
- [Ivan] I’m against empty braces in queries; adding support to parser for SDL definition can be added potentially.
- [Ivan] Let’s not put the carriage before the horse - we’re not sure that we will be implementing the object extensions feature (the main motivation for this) in a way that will require this.
- [Lee] Catch up with folks from Twitter regarding one of the patterns this RFC approaches
- [Sasha] I’d like to think a bit more about it (the result handling we are still in the beginning stages of using at Twitter) but generally I like where this is going . I'm not sure I've seen all of the proposals
- [Lee] [Action - Victor] Lets re-frame it in terms of the specific problem rather than expressing all the problems that it could potentially solve.
- [Benedikt] Accepting this would make the spec simpler because there’s no more “requires at least 1” wording.
- [Lee] We don’t want to support marker interfaces - interfaces should require at least 1 field
- [Lee] Relaxing the definition for objects, i.e. for algebraic types deserves its own focus
- [Lee] Metadata adding to types needs a crisper definition with competing approaches - requires more discussion
- [Benedikt] [Potential action item] Split the proposal up, since we may want to allow empty input objects
- [Craig Smitha…] When you’re modelling your API/domain modelling and you’re using interfaces heavily, it may make sense to have empty interfaces for a period of time before you know
- [Dan Schafer] Upgrading from union to interface is challenging, but from empty interface to interface with fields is easy. Maybe we want to make moving from union to interface easier, but that comes with complexity vs capability tradeoff.
- [Ivan] Looks great, but code samples may be problematic. Many languages; needs to be updated frequently. Maybe just URLs instead.
- [Tanay] Let's do further discussion in the PR
- [Lee] [Action - Lee] Grant access to Tanay and Orta
- [Lee] [Action - Lee] Give detailed feedback
- [Mike M] Change cost is mainly just in servers supporting it; enabled more queries to be valid
- [James] Explodes possible fragment conditions for code gen
- [Mike M] Disagree
- [James] Adds complexity to typed impls. Examples: Apollo iOS, Apollo Android, Apollo codegen
- [Lee] Previous discussion about whether interfaces implementing interfaces implies transitive relationship or need to be explicit. Result of previous discussion was the explicit variant which removes that complexity.
- [Mike M] Let’s look offline at specifics of potential complexity added
- [Benedikt|Lee] Explicitly redeclaring all fields of the original interface on the extending interface is in line with how object types and interfaces relate to each other and allows for refining the types and descriptions
- [Lee] Several action Items
- [Action - Mike, Ivan] Alpha version
- [Action - James] Concrete examples of impl complexity
- [Action - Mike] Ensure that test cases are present
- [Lee] Close to stage 3. Just need to address issues and we can probably discuss stage 3 in next meeting.
- Recent additions:
- Problem Statement
- Problem Sketch
- Requirements
- PR: "Prior Art"
- [Vince] Many potential edge cases if you try to get too fancy.
- [Lee] Be initially “maximalist” with requirements. List anything that could be a requirement - then look at which ones actually need to be requirements. Otherwise new potential requirements appear later and invalidate any proposed approach. This is a good start - provides a ton of clarity.
- [Benedikt] Create a table that shows which solutions meet which requirements
- [Ivan] Some requirements are “soft”. There are requirements and trade-offs. Propose one restriction: If there is opposition, document the trade-offs.
- [Vince] Let’s call this objections. List objections and rational.
- [Ivan] Doesn’t need to be personal. Not a stable working group. Just document objective tradeoffs with each proposal.
- [ACTION - Everyone interested in input unions] Contribute to the Input Union RFC document before the next meeting to make requirements/tradeoffs clearer.
- Requirements
- Objections
- [Benjie] Aims, Tradeoffs, and Requirements
- Requirements - what MUST it do?
- Aims - what would we LIKE it to do (e.g. inputs and scalars)?
- Tradeoffs - what controversial issues does it have?
- [Lee] In the past we’ve been blocked; want to avoid that
- [Lee] Initially, just capture everything - doesn’t need to be internally consistent, or achieve any consensus
- [Benjie] Sounds reasonable
- [Vince] Like Aims & Objections vs Requirements
- [Ivan] Agree - no need to specify hard vs soft requirements. One big section for Aims is fine. “Requirements” sounds like we’re committing to something
- [Vince] Is there veto power or approval authority?
- [Lee] Goal is for this WG to reach consensus. Allows us to answer to the community about why changes were made.
- [Lee] Default is no change.
- [Lee] Currently the steering committee is me, but I’m working on expanding that group.
- [Vince] How do we define consensus? Does it need to be unanimous? Can a single loud voice prevent action? We should clarify.
- [Lee] We should have a way to move forward. One loud voice shouldn’t be able to block progress. Currently this relies on me, but this isn’t scalable and I’m working on that. Ultimately should land on steering group to decide.
- [Evan] As group expands, reaching consensus is slower. Should limit attendance or provide structure.
- [Michael Staub] Limiting attendance isn’t the answer. For Input Unions proposal specifically, its challenging because there is no perfect solution.
- [Lee] This meeting isn’t the best place for brainstorming. This meeting is useful as a status check and way to move things forward and gain clarity.
- [Evans] That works to do things offline or async and use this time mainly for status checks
- [Ivan] Would be nice to stream to YouTube for spectators
- [Lee] We accidentally hosted this on the wrong Zoom account so couldn’t record it, but we’re going to be better in future