We ran into a production bug recently that was caused by the user running an old version of client side code (that was incompatible with recent changes in the server side api) due to not refreshing their browser in several days. Before we went about implementing a fix internally, I wanted to check and see if there had been any thought in the community around how to force clients to update in the event that there are updates pushed for client side code.
One thought I had for fixing the problem internally was having the server make a SHA of each of the client side javascript files that’s sent to the browser, similar to how the Rails asset pipeline fingerprints precompiled assets. Then, send the SHA’s down as part of the initial page load and on every API request that Ember makes, send the SHA values through as request headers. Those request headers could then be checked by the server to see if there is a more recent version of a client side file and, if so, send back an error that can be handled by the Ember App; perhaps by forcing a browser refresh.
Anyone encountered this problem themselves and, if so, what approach did you take? See any problems in the proposed implementation?
The SHA idea is good – we handle this exact problem in our production app with a simple string version though (e.g. 1.0.1), and it seems to work fine. The services on our backend all reply with the current app version in their message. In addition, we poll the server every hour when the app is running.
Our build server automatically bumps the version number, which we simply store in a text file on the server. The client app forces a refresh if the versions are different.
An architecturally different approach to the problem would be to version your service interface, and run multiple side-by-side versions (when changing the interface, not the implementation). Just food for thought - doesn’t seem like the best solution for your problem.
Hey guys, I just wanted to chip in with my 2c on this because you guys seem to be hovering around the way we do it but haven’t quite hit it yet and I quite like the way we do it.
If you look at what they structure the Grunt file you will see that they use grunt-rev to solve this exact problem! The idea of grunt-rev is that they do a form of hashing for each file and append the hash automatically to the file. This means that you won’t force an update on some files that haven’t changed and you will on the ones that have.
Hey everyone, thanks for the great replies! Great food for thought all around. @zacharyyates I really like the idea of incrementing the version number as part of the build process and then sending that through on each of the api requests. I could see different clients of an API having different needs for forcing a reload.
Also, thanks @real_ate, we’re using the asset pipeline for concatenating and minifying assets and it also appends the sha to the final file name. But, I’ve been advocating for a move to Grunt and it’s really nice there’s a plugin that provides that same capability.
and I quite like the way we do it.