I ran into a strange issue where an old browser tab was still using a previous frontend build after deployment. An API change was introduced, and requests from that stale bundle started failing. For situations like this, is it better to keep the API backward-compatible for some period, or should the application detect the mismatch and force a refresh when a breaking change is deployed?
3 Answers
A smoother option is to have every API response include the current frontend or deployment version in a header. The frontend can compare that value with the build version embedded at compile time. If they differ, show a message saying a new version is available and offer a refresh, instead of letting an unrelated API request fail unexpectedly.
Version the frontend assets so browsers and CDNs don’t keep serving stale files. Content-hashed filenames, such as those generated by Vite and similar build tools, are a good cache-busting strategy. For the API itself, backward compatibility is preferable; if that isn’t practical, expose a new API version such as /v2 rather than breaking existing clients.
For a simple app, catch the failure and trigger a refresh. It’s quick and usually solves the problem, although you should avoid creating a reload loop if the new build still has an issue.
That sounds less disruptive than forcing a reload immediately, especially for users who might be in the middle of entering data.