Ember in production: Outdated clientside code

1

So, we’re busy rolling out the first alpha version of our Ember UI in production. The idea is to currently just run tests on CI and then replace files with ember-cli-deploy and scp. I should have thought of this much earlier, but it just occurred to me that clients might very well have outdated client code. We deploy multiple times a day, and this might be an issue. Is there a best-practice solution to this issue? How does Pivotal Tracker do it? I assume something like a web socket that pushes out a notification when an update has been pushed out? Or perhaps a forced page refresh if the person has been idle for X amount of seconds and there are no dirty models?

1 Like
2

Hey! We’ve been noticing this problem for a long time in our app, people leave the same tab open for days, or weeks even. In the past sprint we added a solution to help deal with this. Here are the details of our solution.

  1. When we serve up our app’s HTML file, we inject our “build version” into the page as a meta tag, not unlike we do with our CSRF.
  • The build version is incremental, so each version is greater than the last comparatively.

  1. ALL HTTP requests have a “version” attribute as a response header. In our case, it’s X-Batterii-Version and X-Batterii-Min-Version.

    (Ignore the fact that it’s just “1”).

  2. In our adapter, as part of every ajax response we read the X-Batterii-Min-Version header and compare them to what’s been embedded in the HEAD. If we find that X-Batterii-Min-Version is greater than the embedded one, we prompt the user to “optionally refresh” the page.

  • We do this by having an “ApplicationService” with a flag on it. Our application.hbs template has an {{if}} binding for that flag to notify the user.

Thus far it’s worked quite well. Hope that helps.

3 Likes
3

This is an awesome method, thanks!

4

FYI, just came across an addon that seems to do exactly this. https://github.com/xcambar/ember-cli-self-update