-
Notifications
You must be signed in to change notification settings - Fork 193
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
Putting data on edges (or not) #52
Comments
I think that's correct. Also I just verified that Shopify's schema still has no edge types with additional fields as a confirmation. This makes sense to capture and I'm in favour as well if you want to contribute it |
If edges are boilerplate and can just be ignored, then why do we have them? There is the One field that's generally put on edges is the In the scenario where data is actually naturally stored on the edge (e.g. in a friend relationship between two users, with status and timestamps etc on the edge), then, without the data on edge, we'd need a |
Yeah, the boilerplate edge types still need to exist in order to hold the In the scenario where data is naturally stored on the edge, then yes, you do need to manually create a GraphQL type for each edge or "join table" or however you think about it. But these types can be bidirectional at least (e.g. you don't need both |
This is a design topic which has been discussed a bunch internally at my current company, and which is not addressed in the design tutorial. IIRC at Shopify we ended up at (what I believe to be) the correct answer without much discussion and never really thought about it, but in hindsight I think that was a fluke, and it's worth making an official design ruling on. This should probably be worked into the design tutorial, or tacked on as another appendix or something.
My current belief is:
While there are some cases where putting data directly on connection edge types is OK, there are many where it ends up causing issues, and should be avoided; it is best to adopt the simple rule never to put data on edge types. This may result in a few extra types in the schema, but simplifies reading/interpretation because it becomes safe to assume that edge types are always just boilerplate and can be safely ignored.
The cases where putting data on edges can cause issues include:
AXEdge
andBXEdge
etc. instead of the standard/default generatedXEdge
, which can't reasonably have edge-data for two or more different relationships.The text was updated successfully, but these errors were encountered: