Add 'extensions' to request #976
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
✅ Deploy Preview for graphql-spec-draft ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
n1ru4l
approved these changes
Aug 1, 2022
Motivation: IsSubType could be re-used in graphql#973
Co-authored-by: Roman Ivantsov <roman.ivantsov@microsoft.com>
Co-authored-by: Benjie Gillam <benjie@jemjie.com> Co-authored-by: Roman Ivantsov <roman.ivantsov@microsoft.com>
…pe (graphql#974) * Fix: implementing field type is either exact match or covariant type * Match language in IsValidImplimentation Co-authored-by: Roman Ivantsov <roman.ivantsov@microsoft.com> Co-authored-by: Lee Byron <lee@leebyron.com>
…non-repeatable directives (graphql#975) * Fixed the explanatory text for algorithm checking uniqueness of non-repeatable directives * lint * lint fixes Co-authored-by: Roman Ivantsov <roman.ivantsov@microsoft.com> Co-authored-by: Lee Byron <lee@leebyron.com>
field merging - field TYPES must not differ Co-authored-by: Roman Ivantsov <roman.ivantsov@microsoft.com> Co-authored-by: Benjie <benjie@jemjie.com> Co-authored-by: Lee Byron <lee@leebyron.com>
This does a few things to simplify testing and CI: * `npm test` locally will now include format checking, which previously it did not. This means if you run `npm test` locally you can be fairly sure that CI will pass. * Broke out CI jobs to run all test sub-steps in parallel. This should make it a little easier to understand why a PR failed CI. * Remove the dedicated prettier workflow (in favor of the one in test/CI) * Updates prettier and action versions
Co-authored-by: Benjie Gillam <benjie@jemjie.com>
Clarify that a schema definition must be present (and not omitted) if a default root type name happens to be used by a type which is not a root type. Also adds an editorial change to introduce term definitions for the immediate concepts involved. Co-authored-by: Lee Byron <lee@leebyron.com>
…raphql#1009) Adds how to contribute custom scalar specs, links to spec templates, and adds examples following the launch of https://scalars.graphql.org Co-authored-by: Benjie <benjie@jemjie.com>
Co-authored-by: Benjie <benjie@jemjie.com> Co-authored-by: Roman Ivantsov <roman.ivantsov@microsoft.com>
JoviDeCroock
approved these changes
Mar 6, 2024
* Consistent punctuation in algorithms * Clarify style guide * Boolean formatting * Add a format check to CI
|
Conclusion from the latest working group meeting is that we should be more explicit about all of the things in request. This was also one of the options laid out by Lee back in 2022:
|
benjie
added
💡 Proposal (RFC 1)
|
(It was agreed that this was something that we probably should have in the spec though. Although not explicitly stated as such, I've moved it to RFC1.) |
* Be strict about error paths * Update spec/Section 7 -- Response.md Co-authored-by: Benjie <benjie@jemjie.com> * format --------- Co-authored-by: Benjie <benjie@jemjie.com>
…es (graphql#1032) * Define selection set * Consistent casing of 'selection set' * Convert an example to a mutation operation * Add operation name and variables
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It's common in the ecosystem to use
extensionson a GraphQL request to share additional information with the server; for example Apollo Persisted Queries uses it to indicate the hash of the document to execute.Currently the GraphQL Spec specifies an "extensions" field on Response but not on Request; I'm trying to determine if this is a purely transport-level concern (i.e. should be specified in GraphQL-over-HTTP, etc), or if it should be specified in the spec proper. IMO the spec should have at least a note indicating the use of the "extensions" field.
The specification of the format of a request is somewhat fuzzier than the format of a response; this is not unexpected because GraphQL is so flexible in how it is consumed, and persisted operations/etc should be spec compliant without having to be specified therein. So the request doesn't really speak of specific keys, more here's the information we need to execute, and "extensions" is not amongst that information. Nonetheless, standardising extensions as a key for expansion would be beneficial to the community.
It's worth noting that GraphQL.js does not include
extensionsamongst the arguments tographql(): https://github.com/graphql/graphql-js/blob/699ec58547c34bfeef866a2a4458615d39b16964/src/graphql.ts#L20-L68 . Nor does express-graphql look atextensionson a request as far as I can tell.