-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Extend Versioning paragraph in Best Practises #146
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
Comments
As far as I understand best practices are to keep your old field and add the new one. https://facebook.github.io/graphql/#sec-Object-Field-deprecation But yeah I agree that a dedicated section about versioning could be a good idea. |
Thansk for your reply. I just saw that Facebook is still versioning their GraphQL API in the URI. Two other questions: How do you deprecate a whole type? How do you deal with mutations? |
Are they? I haven't heard anything about this, as far as I know they've been using the same schema since the beginning. If anything, I suspect this is because they have rewritten the entire syntax and so they would need a separate endpoint for the old query language.
I imagine you would deprecate all fields that point to that type. And you can deprecate mutations the same way, since they are just normal fields. |
The Graph API is not the same thing as GraphQL, even though they have similar names. Facebook doesn't have a public GraphQL API at all. |
The need for a versioning page is already recorded in the new site plan: #41 Going to close this issue then. |
Ah right, then I messed it up a bit 😊 |
The Versioning in the Best Practises section is explaining why traditional REST APIs need Versioning to deal with breaking changes. But later sentences don't explain what are the best practises with GraphQL do deal with breaking changes. For example how should I handle the case when I want to remove or rename a field of a type?
The text was updated successfully, but these errors were encountered: