STstriking·Jul 8, 2020
If you've made a catastrophic and backwards-incompatible error, a common solution is to write "V2" fields and then reimplement the previous iteration's fields with the new resolvers. Old clients will then be able to continue to resolve fields they expect, while new clients will be able to take advantage of new features. This is generally pretty rare, because usually the usecase is that you're expanding the graph, and generally if you have followed the rules and best practices in writing the graph then expanding the graph should just work in a backwards-compatible way.
(aside: I agree that changing your graph / domain model is likely, and I take a dim view of tools that automatically generate APIs as a result.)
I've also seen https://github.com/ef-eng/graphql-query-rewriter and consider it an interesting thought, but have never seen it in
Read the rest
production (and most people are rightly worried about doing such a thing).
GraphQL is our API for our frontend team, but it's also our API for end user devs. We just run it through an app that generates a REST API from a subset of our usual schema graph. (The decision was made not to expose the raw subset itself mostly just to cut down on docs duplication and avoid confusion for clients that don't know or need to know GraphQL.) This comes with advantages like allowing the use of `_expand` fields like you'd see on Stripe's API (https://stripe.com/docs/api/expanding_objects), without us having to break a sweat.