Support for nonexistent javascript deployment

Question

Background:

I have a one page website that is deployed to production at least once a day. It receives a reasonable amount of traffic, and users stay on it for a sufficient amount of time until they check, and JavaScript interacts with the backend via XHR.

Problem:

After deployment, JavaScript loaded in the browser can no longer be backend compatible (Rails in this case).

Possible solutions:

a) Compare the pipeline fingerprint with the assets at a regular interval, window.confirm, with a restart request if it is not the same.

b) Send an X-JS-fingerprint header with XHR requests, if it is incompatible, return a 409 conflict that JavaScript will throw an error, and reload the .confirm window .. p>

c) Run two backends; the one that is deployed immediately with the new JS and the new internal code (SERVER-1), the other remains support for the old XHR JavaScript request formats (SERVER-2). As b) an X-JS-fingerprint header will be sent, but instead of 409 it will send a 307 temporary redirect to SERVER-2 to complete the request. Once the old sessions are cleared, SERVER-2 will be deployed and shut down until it is needed again.

I am wondering if anyone has thought of this problem before. If you have thoughts on this, please let me know.

Answer 1

There is a diffable project that was created at Google for similar use. The basic idea is that it is somewhat similar to your option a . The only difference is that when the client detects that the server is being updated, it automatically updates the client code base and does not load all the resources, but instead loads the diff patches and applies them on the client. It may seem a little crazy, but it actually makes sense in terms of performance.

There is also a successor idea that uses localStorage to store the client codebase. See also his https://github.com/plotnikoff/connect-diffable Node project, but it can still be useful only for getting an idea.

You can change the approach for your case and have something like:

• Store client complaints in localStorage. There are checksums for each version.
• Everyone now or often requests a server to determine if a new version has been released.
• If there is a newer version, request a patch and apply it to the assets in localStorage, check the checksum. (Here you can send checksums of new versions together with patches to compare them after application).

Answer 2

I ran into this problem. My solution is very simple and is not really trying to avoid errors for the user. This is similar to your decision a .

I save the version number, for example, a fingerprint (all files also have fingerprints, CSS / JS). The deployment process automatically increments the version number. Even if I just changed one line of CSS, the version number is incremented. I do not distinguish between major or minor changes in the version, this is only semantics.

The application checks the server so often to check the version. If the version changes, “please reload the page” appears, a pop-up window appears. (A non-intrusive little thing at the top of the page, which is very noticeable and obvious and needs to be pressed). If the user does not restart, you may encounter errors, so I will also turn off the error report if the version does not match.

This solution ensures that eventually people will switch to the new version and you won’t get any errors during the user switch. It does nothing to transfer old sessions or prevent errors for the user.

I would not do window.confirm . Unexpected modal dialogs are very annoying. If you type something and press [space-bar] or [enter] , the dialog disappears and you skipped it.

Solution b may seem nice, but there is a flip side. You may be able to detect version mismatch earlier, but it may also mean that your users see more errors. Update, if only a small part of the website affected the update, any XHR request will fail, even if it did not need to fail. This is what you need to consider.

Solution c is very pleasant for the user, but can improve hell. What if your database model changes? The old server will not be able to manipulate the data correctly, requests will fail, etc.

---

I like solution a because it is very simple, and if you update a lot of small changes frequently, the impact of each update is very small.