Watch the replays: GraphQL Working Group Meetings on YouTube
- Jovi
- GraphQL WG — February 2024 (Secondary, APAC)
- Did not go ahead
- GraphQL WG — February 2024 (Secondary, EU)
- Did not go ahead
- Ready for review
- None ready for review
- All open action items (by last update)
- TSC Elections complete, closed now as discussed as well in last meeting
- Reminder: check your implementation, error paths changing from a should to
a must
- Let us know if this would be an issue for your implementation!
- Request for everyone to review the full schema’s RFC by Martin
- Closing as an action item and bringing to future WG to discuss again
- Benjie requested reviews for exclude selection to exclude root set, change
in algorithms
- Closed but reviews still appreciated graphql/graphql-spec#1039
- Add validations graphql-js deprecated on object still pending
GraphQL Grant Refresh (5m, Benjie)
- We have had a grant program running for the past years
- Switching to a continuous process for the grant program
- You are able to apply at any time
- Jory and Benjie will function as a first line of filtering
- Then it goes on to the TSC for review - funding amount, …
- Goal: tighter response time from requesting grant to receiving feedback
- Goal: more transparency
- Any project within the GraphQL organization, code, blog posts, …
- Example: RFC from a year ago but you had no time to progress, some funding might help, please apply!
- Read the blog post and the application page.
- #1073 - Strict error paths
- Context: nullability and errors
- Currently: when an error occurs we should return a path from the operation-root to the errored field
- Future: this should would become must
- This helps with strict semantic nullability
- How do we move forward?
- Matt: 2 TSC approvals - so just get it in?
- Benjie: we need a quorum of active TSC members, with that we could merge it
- Benjie: might make sense to wait 1 more month to allow for other implementations to provide feedback, merge by next working group
- Benjie: we have pinged implementors but not much response
- Martin: GraphQL Java is okay
- Benjie: we should improve at talking to the implementors of different implementations
- Benjie: Please check in with maintainers for feedback
- Action item: Merge this by next working group if no other blocking reviews arise
- Action item: Reach out to maintainers of different GraphQL implementations for feedback on this
- #1078 - Minor wording
change
- Action item: Check out wording in GraphQL.js to ensure this wording change can’t cause confusion and add non-normative note explaining composite referring to object/interface/union
- Glossary is an interesting idea but a big lift for this one in particular
- #1081 - Fragment arguments amendments
- #4015 - Fragment arguments parsing in GraphQL.JS (execution PR linked in description)
- #1082 - Proposed spec changes for string literal aliases
- #4023 - Add parser support for string literal aliases
- Big lift, sharing context why and what the problem is.
- Data consistency, multiple screens fetch data over GraphQL
- When the data changes we want to be aware of that
- Queries within the same session should be able to update each other
- Relay uses a mapping of the alias name to the canonical name
- fieldName + fieldArguments
- Right now we are experimenting where we use the alias to encode the
canonical name, the canonical name can include illegal characters for the
GraphQL spec due to arguments
- We are trying to understand whether we can do this without changing the spec, experiments with custom escape format “z” is an escape character because it’s the least used char in the GraphQL alphabet
- The alternative is a spec extension that uses a double quote for aliases which allows for all characters (string literal aliases)
- How do folks feel about the issue of data consistency
- Martin: apollo-kotlin could benefit from this as well as it ships with codegen that embeds some of this as well
- Jovi: how does the normalized cache fall short
- Matt: It does not, it’s a network optimisation as we have less in memory as the canonical name can be pre-computed
- Stephen: we solved this early at Netflix with Falcor and its JSON graph design, going to GraphQL we haven’t done any special workarounds and we haven’t seen any regressions there. We have the same need to normalize across your experience. In falcor we use references so if you have something in your response it’s only in one place.
- Martin: did you consider something like meta fields
__canonicalName - Matt: that doesn’t work for scalars as we’d need a selectionSet
- Curtis: internally at meta we have collected a number of features that we
do that make up this normalized cache ecosystem.
- Canonical name
- Strong directive
- Fetchable directive
- Curtis: would be valuable to put this more cohesively together within GraphQL. Having references in the response and use it only once, we have played with this and we named it “graph-mode”. One of the concerns with graph-mode was how well it streams.
- Benjie: posts link to graphql-crunch https://github.com/banterfm/graphql-crunch
- Benjie: GraphQL Crunch is an open implementation of references, have you considered building it as a protocol extension on top of GraphQL, adding it to the extensions object.
- Benjie: Name being limited is controversial in GraphQL but the limitation makes it work in every programming language.
- Curtis: RFC is a strawman and no intentions of merging it atm, feedback is already hugely appreciated!
- #1016 - fix a single word
- We missed one word replacement, 2 TSC approvals so… merged!
- #1032 - define "selection
set" (already has 2 TSC approvals)
- This relates to some common misreading of the specification, it talks about serial execution of a selection-set. Mutations have serial execution of a selection-set, folks get confused when reading the examples as they think it’s a query operation using the short-hand.
- The PR makes the PR’s explicit by either having mutation explicitly or a note
- The PR also explicitly defines selection-set which we were missing in the specification
- Kewei: the mutations are missing variables
- Benjie: good catch, addressing it!
- Action item: review and get it merged if approved after the above is addressed
- #894 - clarify "before
execution starts" still includes the "request error"s that can be raised in
ExecuteRequest() (variable coercion failure; not exactly one subscription
field assertion failure)
- We have text that refers to “before execution begins”, we however don’t define that anywhere.
- In order to help with clarifying the text we add a normative note explaining this
- #1069 - enforce
consistent punctuation in the spec (with CI check)
- We are currently quite inconsistent in the spec, we sometimes forget curlies, …
- This PR adds some code that checks the language and enforces the punctuation to adhere to our own rules
- RFC
- Aim: advance to RFC1, or reject to RFCX.
- The GraphQL Over HTTP spec needs to specify the extensions key for requests
- Example Apollo SHA256 for persisted operation
- Should this be in the main spec?
- Lee’s initial thought was that we don’t need it as the spec doesn’t rely on it.
- The main concern with that is that every transport spec needs to redefine this concept for request.extensions
- Matt suggested a middle spec that defines more clearly how transport layers could work
- The GraphQL Over HTTP spec needs to specify the extensions key for requests