Luke Champine

AFAIK there aren't formalized tools to manage these kinds of migrations. This is surprising to me because it's so closely analogous to database migrations. Migration happens at runtime rather than deploy time, with requests migrated forward and responses migrated backward.

A number of responses say "have the client detect that it's running an old version and force reload." That works, but it's pretty annoying UX. Better handling of migrations on the server side could prevent that. (With an eventual timeout to ease the support window: maybe a week?)

Some responses along the lines of "only make additive changes" and other similar rules. But these add a lot of inertia. If the server's API version support window were enforced by tools, then you could add and change fields at will and it would force you to write the migrations.

This seems like the more disciplined end of the continuum today, but it's still manual: create an issue, manage it, etc. I want to make incompatible API changes and have the system force me to write a migration so old clients don't need to restart.https://twitter.com/jacobrask/status/1140719143408287747 …

This thread got many interesting replies about what people do for syncing client/server API changes, especially on the original tweet. Lots of what you'd expect ("manually avoid backwards-incompatible changes") and also some very fancy technical solutions (fewer of those).

Imagine: - Unbroken static typing from the database, over the API, to the frontend. - Database gets migrated forward, statically checked against backend database access. - API gets migrated backward, statically checked against backend responses and all running frontend versions.

I have the first two working. It's obvious that the third is possible, though it's not yet obvious to me that it's cleanly expressible in popular static languages.