Skip to content
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

Open
wants to merge 24 commits into
base: main
Choose a base branch
from

Conversation

magicmark
Copy link
Contributor

👋

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!

@magicmark
Copy link
Contributor Author

magicmark commented Nov 18, 2020

Oh also, here's another option I had for the examples table, was thinking it might be good to explicitly show all the different kinds of schema you can select:

Screen Shot 2020-11-17 at 10 38 01 PM

felt slightly too verbose to me, but curious to see if anyone prefers this

Copy link
Member

@benjie benjie left a 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!

spec/Appendix C -- Schema Coordinates.md Outdated Show resolved Hide resolved
spec/Appendix C -- Schema Coordinates.md Outdated Show resolved Hide resolved
spec/Appendix C -- Schema Coordinates.md Outdated Show resolved Hide resolved
spec/Appendix C -- Schema Coordinates.md Outdated Show resolved Hide resolved
spec/Appendix C -- Schema Coordinates.md Outdated Show resolved Hide resolved
Copy link
Member

@benjie benjie left a 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 Show resolved Hide resolved
spec/Section 3 -- Type System.md Outdated Show resolved Hide resolved
spec/Section 3 -- Type System.md Outdated Show resolved Hide resolved
spec/Section 3 -- Type System.md Outdated Show resolved Hide resolved
Comment on lines 379 to 399
Schema Coordinates are always unique. Each type, field, argument, enum value, or
directive may be referenced by exactly one possible Schema Coordinate.
Copy link
Contributor Author

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

Comment on lines 382 to 391
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.
Copy link
Contributor Author

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

Copy link
Contributor Author

@magicmark magicmark Jan 4, 2021

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!

Copy link
Member

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 since Business already uniquely identifies the Business 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.

Copy link
Contributor Author

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

magicmark added a commit to magicmark/graphql-wg that referenced this pull request Jan 4, 2021
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!
@leebyron leebyron added the 💡 Proposal (RFC 1) RFC Stage 1 (See CONTRIBUTING.md) label Jan 7, 2021
Base automatically changed from master to main February 3, 2021 04:50
@mcohen75
Copy link

mcohen75 commented Feb 4, 2021

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.

👍 👍 👍

@leebyron leebyron added 📄 Draft (RFC 2) RFC Stage 2 (See CONTRIBUTING.md) and removed 💡 Proposal (RFC 1) RFC Stage 1 (See CONTRIBUTING.md) labels Mar 4, 2021
@leebyron leebyron added this to the May2021 milestone Apr 13, 2021
@leebyron leebyron force-pushed the schema_coordinates_spec_edit branch 3 times, most recently from 4f854af to c0b82d5 Compare April 13, 2021 23:57
@leebyron
Copy link
Collaborator

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.

@leebyron leebyron force-pushed the schema_coordinates_spec_edit branch 3 times, most recently from 81ef020 to 4299d8c Compare April 14, 2021 01:18
@leebyron leebyron requested review from benjie and a team April 14, 2021 01:20
@leebyron leebyron changed the title Schema Coordinates: add spec edit Schema Coordinates Apr 14, 2021
@leebyron
Copy link
Collaborator

IIRC the only thing holding this from Approval stage is a landed GraphQL.js PR?

@magicmark magicmark force-pushed the schema_coordinates_spec_edit branch from e6f7939 to 93bd2c6 Compare December 10, 2024 17:15
Copy link

netlify bot commented Dec 10, 2024

Deploy Preview for graphql-spec-draft ready!

Name Link
🔨 Latest commit d61cdc3
🔍 Latest deploy log https://app.netlify.com/sites/graphql-spec-draft/deploys/67587f186771b30008b11945
😎 Deploy Preview https://deploy-preview-794--graphql-spec-draft.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

@cheapsteak
Copy link

@magicmark

@cheapsteak do you have an example syntax for what you had in mind? If i'm understanding correctly

yup for sure 🙏

e.g. using Yelp's schema, something like Business.id~description to address the description of the field, or Business~description to address the description of the type, or Business.id~returnType to address the return type of the field

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

@benjie
Copy link
Member

benjie commented Dec 11, 2024

Alternative syntax: Business.id#description inspired by Ruby/PHP/Elixir.

If we want to explore this, we should explore it further:

  • Animal#description
  • Animal#members
  • Animal#members#Cat -- Not currently useful?
  • Animal#members#Cat#deprecationReason -- Not currently possible to deprecate union members
  • Animal#members#Cat#description -- Not currently possible: union members can't currently have descriptions. Note: NOT the same as Cat#description.
  • Cat#description
  • Cat#deprecationReason
  • Cat.lives#description
  • Cat.lives#deprecationReason
  • Cat.lives#type
  • Cat.lives(includingSpent:)#type
  • Cat.lives(includingSpent:)#description
  • Cat.lives(includingSpent:)#deprecationReason
  • MyEnum#description
  • MyEnum#deprecationReason
  • MyEnum.MY_VALUE#description
  • MyEnum.MY_VALUE#deprecationReason

Technically until we have #300 or similar we can't represent arbitrary directives on a position, but arguably we should consider that too:

  • MyEnum.MY_VALUE@myDirective{3}(arg:) < the arg argument on the third myDirective (repeatable) directive applied to the MY_VALUE type on the MyEnum enum. 😅

@cheapsteak
Copy link

@benjie that all looks great! 🙏 although one nit with # is that it's not url safe and would need to be escaped

@benjie
Copy link
Member

benjie commented Dec 11, 2024

Sadly same is true already of : - though most browsers can handle it unescaped, if you put it through encodeURIComponent it will be escaped:

> encodeURIComponent(':')
'%3A'
> new URLSearchParams({a: ':'}).toString()
'a=%3A'

@magicmark
Copy link
Contributor Author

magicmark commented Dec 12, 2024

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
📄 Draft (RFC 2) RFC Stage 2 (See CONTRIBUTING.md) 🚀 Next Stage? This RFC believes it is ready for the next stage
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants