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.
Anyone encountered this problem themselves and, if so, what approach did you take? See any problems in the proposed implementation?
I have not dealt with this yet myself.
I like your idea of versioning with a SHA to force browser reload or whatever.
You could use the deployed git version SHA.
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.
We’re using grunt to build our Ember app, actually we started with Yeoman builder for ember
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.
Hope this helps!
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.