Not a general solution, but with Hasura, one approach we have seen is to use Postgres views to keep the old graph around as your data model changes.
In general API evolution is tricky and perfect decoupling between API clients and servers not possible (the article talks about this). What one can aim for is a combination of:
1) Adding new query parameters should not break clients
2) Adding new fields to the responses should not break clients
3) Adding new serialization formats (for newer clients) should not break existing clients
#1 & #2 is roughly what you get with GraphQL optional fields.
Phil Sturgeon has good articles on API Versioning[1] and Evolvability[2] for REST API's
"perfect decoupling between API clients and servers not possible "
Well, the ultimate REST client: the browser, comes pretty close to that.
It doesn't care if you are rendering an app to manage your bank account or a blog or Hacker News.
Comments
Not a general solution, but with Hasura, one approach we have seen is to use Postgres views to keep the old graph around as your data model changes.
In general API evolution is tricky and perfect decoupling between API clients and servers not possible (the article talks about this). What one can aim for is a combination of:
1) Adding new query parameters should not break clients 2) Adding new fields to the responses should not break clients 3) Adding new serialization formats (for newer clients) should not break existing clients
#1 & #2 is roughly what you get with GraphQL optional fields.
Phil Sturgeon has good articles on API Versioning[1] and Evolvability[2] for REST API's
[1] https://apisyouwonthate.com/blog/api-versioning-has-no-right... [2] https://phil.tech/2018/api-evolution-for-rest-http-apis/
"perfect decoupling between API clients and servers not possible "
Well, the ultimate REST client: the browser, comes pretty close to that. It doesn't care if you are rendering an app to manage your bank account or a blog or Hacker News.