-
Notifications
You must be signed in to change notification settings - Fork 9
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
Add enum merging RFC #53
base: main
Are you sure you want to change the base?
Conversation
rfcs/enum-merging.md
Outdated
- **Prevents Runtime Errors**: By ensuring that only recognized enum values are exposed, runtime errors are minimized. | ||
- **Composition-Time Validation**: Differences in enum definitions are caught during schema composition. | ||
- **Explicit Control**: Developers explicitly manage enum exposure, increasing schema clarity, with the hope that they will not return the inaccessible values until they are exposed. | ||
- **Supports Evolvability**: A new enum value can be added by flagging it as `@inaccessible` in a subgraph which hides it from the gateway schema. The other subgraph can then expose it when ready. The flag can be removed once all subgraphs are updated. |
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.
If we have one subgraph, the first subgraph can add @inaccessible
but then the other two can add the enum with out marking it as @inaccessible
. That is by design of the current @inaccessible
directive today with fields but should we make that more explicit with enums?
Maybe we should make it so everyone has to add @inaccessible
? But then everyone has to also remove it to release and that is more work and time....
@PascalSenn @benjie I pulled up some usage stats on the 3000+ enums in our graph: |
Thanks for the stats @fotoetienne ! |
No description provided.