froi
froi

Reputation: 7768

Forcing refresh on client side browser whenever java script is out dated

When we deploy new versions of our application, there is a chance that our users might still be using old front end java script code that may cause errors.

Our app is a single page app, so people do not refresh it a lot, and users sometimes leave it up for a while. So this problem is really prone to happening whenever we push new code.

We were thinking maybe putting up a popup with a refresh button that will force them reload the front end cached code.

How do you trigger that normally? There are lots of ways I can think to do it, but maybe there is a standard way of doing it?

Upvotes: 0

Views: 1224

Answers (4)

Brad
Brad

Reputation: 163234

You effectively have two independent problems.

  • API version mismatch between client and server
  • Accelerating the release of new versions of the code.

API version mismatch

Typically, you'll want to use a versioned API. Each API request should somehow indicate which version the request corresponds to. This is often done in the path of the request, which makes routing to different API servers very easy to do. For example:

http://api.example.com/1.0/foo/bar

Your web server can match on /1.0/ and route to the appropriate application server for your API.

This gives you some flexibility, allowing a rolling release process and not forcing clients to reload every single time you do a release. (You may some day want to release 50 times a day, and your clients won't be too happy about that. No need to force a reload unless you have a specific reason to.)

The easiest way to do this is make new versions of your API backwards compatible as much as possible. But, breaking changes do occur. When this happens, run two instances of your API server simultaneously. If you have a major underlying data structure change, or some other huge change that prevents this, you will need to stop the old versions at the same time as starting the new, and force a reload.

New client code releases

You'll have to decide based on your app and business conditions whether or not it's a requirement to reload each time you have a release. Again, you might some day want 50 releases in a day, most of those for minor issues that most of your customers will never see. It's common to let the user know that a new version is available and let them reload when they feel like it. You can always force a reload if you absolutely have to (due to critical security issue, or major breaking changes).

Implementation

The specifics of how you do this are up to you, but one simple way is to have a basic JSON file available, indicating the latest versions:

{
  "apiVersion": "1.0.5"
  "appVersion": "1.1.352"
}

More creatively, you could have this file indicate whether or not specific versions need to be killed, and thus a reload forced.

Upvotes: 2

Seth Holladay
Seth Holladay

Reputation: 9539

This is a case where semver really comes in handy. You want to have an automated process that updates the client code. To make sure the update is compatible, you should ensure that there is a way to compare the version strings of the new and old code and determine if it's a "major" update or not. For "minor" or "patch" updates, you can probably update on-the-fly. But for major updates, it would be smart to force a full reload, after helping the user save their work.

In terms of a process for on-the-fly updates, you could use something like AMD modules for this. You would expire the module cache, download the new code, and reinitialize relevant parts of the system (carried out by the new code).

There is also the matter of knowing when updates are available. I would recommend looking at Server Sent Events for this. But if you need Internet Explorer support, you may have to resort to a setTimeout-based polling mechanism, or similar.

Upvotes: 0

trpt4him
trpt4him

Reputation: 1906

You could use a Web Worker to periodically ping a server for a new code change or version number (say from a database) and force a refresh if there's something new. That will give you more on-demand possibilities than if you are just using say, a setTimeout.

Upvotes: 0

Mati
Mati

Reputation: 1148

I would add ?<version> to the script's src.

<script src="myFile.js?1"></script>

You can change this version with a code push for instance, so the client's forced to take a new version, because of the querystring.

Upvotes: 0

Related Questions