How do most SPAs handle breaking API schema changes?
1–10 of 39 posts
Re: How do most SPAs handle breaking API schema changes?
#2Ideally, version your APIs, though for some internal APIs you definitely want to be able to make changes without bumping versions constantly.
Be backwards and forward compatible as much as possible. Rolling deployments and other factors virtually guarantee mismatched versions in both directions. Many things, like adding new fields or removing old ones, can be staged in such a way that nothing breaks. Protobuf/gRPC offers some form of backwards and forwards compatibility (at the data model layer, of course,) if you adhere to certain basic invariants.
Almost any change can be staged over time, how long you want to keep compatibility between versions is up to you.
Oh, probably most important: keep clear data model separations wherever you can. Between storage and API, and API and in-memory state management. It’s a lot of work, but it pays dividends.
Re: How do most SPAs handle breaking API schema changes?
#3[deleted]
Re: How do most SPAs handle breaking API schema changes?
#4When you need to make a backward incompatible change, do it in three steps:
1. Add new stuff to API in a backwards compatible manner (without removing or changing old stuff). When you need to add fields it is usually safe to do it within existing functions. When you need to modify fields, I recommend simply copying and pasting your API function and exposing the new one with a number suffix, e.g. get_messages_2
2. Update the client code to use new versions of functions and to stop using old versions.
3. Once the new client is deployed, wait a while longer and then remove old versions of functions like get_messages_1
You can also use a single global version which will allow your client to detect when it has gone stale and reload.
Re: How do most SPAs handle breaking API schema changes?
#5> 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.
Is it though? Of all reasons to force refresh, this sounds reasonable to me as it won't even happen that often.
Heck, I would want to refresh if I knew a new version was available.
Re: How do most SPAs handle breaking API schema changes?
#6> 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. Is it though? Of all reasons to force refresh, this sounds reasonable to me as it won't even happen that often. Heck, I would want to refresh if I knew a new version was available.
Even Facebook does this when you have left it open in a tab for too long.
[edit]: spellcheck failed.
Re: How do most SPAs handle breaking API schema changes?
#7> 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. Is it though? Of all reasons to force refresh, this sounds reasonable to me as it won't even happen that often. Heck, I would want to refresh if I knew a new version was available.
Is it though?
And whether your SPA is something like Google Docs where a user could plausibly have the same document open for a week or more.
[1] https://blog.newrelic.com/technology/data-culture-survey-res...
Re: How do most SPAs handle breaking API schema changes?
#8I don't know if most SPA frameworks offer this sort of functionality, but with intercooler.js you can send response headers to trigger client-side events (or, if you are feeling hacky, to evaluate raw javascript.)
This can be used to trigger a full browser refresh when the application topology had changed dramatically.
Re: How do most SPAs handle breaking API schema changes?
#9Ideally, version your APIs, though for some internal APIs you definitely want to be able to make changes without bumping versions constantly. Be backwards and forward compatible as much as possible. Rolling deployments and other factors virtually guarantee mismatched versions in both directions. Many things, like adding new fields or removing old ones, can be staged in such a way that nothing breaks. Protobuf/gRPC of…
The question is about web apps, Protobuf/gRPC don't apply. Your comment is speaking in generalities, the question is about what you actually do. Of course you want to preserve backward/forward combat as much as possible, all else being equal.
Re: How do most SPAs handle breaking API schema changes?
#10> 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. Is it though? Of all reasons to force refresh, this sounds reasonable to me as it won't even happen that often. Heck, I would want to refresh if I knew a new version was available.
Is it though? Depends if you're triggering it six times a year or six times a day. Some companies pride themselves on how often they deploy code to production [1]. And whether your SPA is something like Google Docs where a user could plausibly have the same document open for a week or more. [1] https://blog.newrelic.com/technology/data-culture-survey-res...
Is it common to be releasing breaking API schema changes 6 times a day?