-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Schema Coordinates #794
base: main
Are you sure you want to change the base?
Schema Coordinates #794
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your hard work on this!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me; a few optional tweaks suggested.
spec/Section 3 -- Type System.md
Outdated
Schema Coordinates are always unique. Each type, field, argument, enum value, or | ||
directive may be referenced by exactly one possible Schema Coordinate. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
feels like something worth highlighting and being clear about as a guarantee in the spec
spec/Section 3 -- Type System.md
Outdated
For example, the following is *not* a valid Schema Coordinate: | ||
|
||
```graphql counter-example | ||
Entity.Business | ||
``` | ||
|
||
In this counter example, both `Entity.Business` and `Business` would refer to | ||
the `Business` type. Since it would be ambiguous what the "primary key" should | ||
be in an application that uses Schema Coordinates to reference types, this is | ||
not allowed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this waffle? thought it might be helpful to have a little explanation/demonstration of this property
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could just be
- Since it would be ambiguous what the "primary key" should be in an application that uses Schema Coordinates to reference types, this is not allowed.
+ Such ambiguity is disallowed (and hence why this is is invalid syntax).
(More terse, but doesn't walk the reader through why this is bad)
Voting lines are now open!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this counter example,
Entity.Business
is redundant sinceBusiness
already uniquely identifies theBusiness
type. Such redundancy is disallowed by this spec - every type, field, field argument, enum value, directive, and directive argument has exactly one canonical Schema Coordinate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 thanks benjie, stealing this wording
Happy new year! 🥳 It's possible we still want more time for the RFC to marinate, but I'll attend so I can be available to folks to discuss the schema coordinates rfc/spec edit in person. graphql/graphql-spec#794 Thanks!
At Indeed we log usage of schema elements to 1) support deprecation and 2) understand usage from a product management perspective (i.e. is this API we built adding value?). We defined our own coordinate system that is not quite as complete as this spec. A nice benefit of formalizing a coordinate system is that shared tools can be built to solve these and other use cases. 👍 👍 👍 |
4f854af
to
c0b82d5
Compare
I made some fairly significant edits to the prose and examples section in an attempt to simplify. @magicmark please take a look and let me know what you think. |
81ef020
to
4299d8c
Compare
IIRC the only thing holding this from Approval stage is a landed GraphQL.js PR? |
- Make examples table - Tweak the grammar definition
- move schema coordinates to section 3.3.3 - add lee's grammar suggestion
Co-authored-by: Benjie Gillam <[email protected]>
- remove extraneous examples - tighten up wording
https://brians.wsu.edu/2016/05/31/standalone-stand-alone/ Co-authored-by: Benjie Gillam <[email protected]>
e6f7939
to
93bd2c6
Compare
✅ Deploy Preview for graphql-spec-draft ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
yup for sure 🙏 e.g. using Yelp's schema, something like Our use case is allowing users to comment on a particular part of a schema, and while we can dangle them off of the type or field, it's not really the right place |
Alternative syntax: If we want to explore this, we should explore it further:
Technically until we have #300 or similar we can't represent arbitrary directives on a position, but arguably we should consider that too:
|
@benjie that all looks great! 🙏 although one nit with # is that it's not url safe and would need to be escaped |
Sadly same is true already of
|
thanks @cheapsteak! I understand the use case now, makes sense. at this point, things are pretty stable and we've already had many rounds of discussions on the syntax of this spec to reach alignment. it looks like we're near to being able to close this out. so the question is, do we want to try and expand the scope of this rfc and re-open it up, or follow it up with another rfc? my preference would be the latter - there are already discussions around expanding this spec in future (https://github.com/graphql/graphql-wg/blob/main/rfcs/OperationExpressions.md) so I think amending this spec as a separate RFC (which could be opened now) would make most sense to allow us to move forward on these proposals independently. (curious what @benjie thinks on this strategy) |
👋
I've pulled out the proposed spec edits for Schema Coordinates (issue: #735) into this PR.
(The RFC now lives in the original PR: https://github.com/graphql/graphql-spec/pull/746/files)
@leebyron you mentioned it might be possible to simplify the grammar - I played around a bit since the original PR, but I think I need some help here. What did you have in mind?
As suggested, tagging @eapache @mjmahone as additional reviewers as we had some good conversation in last WG meeting about this.
Thanks!