
Dealing with releases of single page applications - xintron
http://www.beepsend.com/2016/03/10/dealing-releases-single-page-applications/
======
swalsh
If this was a problem I was truly concerned about, i'd attack it with
discipline and tinkle bit of versioning. If you're making a breaking change to
the API perhaps you should increment the major version, and support both, and
then sail away the old API when you feel comfortable doing so.

yoursite.com/api/v1/call

yoursite.com/api/v2/call

~~~
hankeypancake
Yes, api versioning would be nice. However, with limited resources (as always)
this takes you very far without it. Api versioning also only handles breaking
api changes (which this doesn't really protect you from, depending on how the
users act to the notification), this also notifies the users to refresh their
browsers for hotpatches regarding the frontend, and also regular feature
releases. So even if you have api versioning in place, I still see benefits
from having this in place

~~~
davidjnelson
Seems like graphql would solve the api versioning problem pretty well.

------
davidjnelson
Cool idea and article.

Hot reloading deployed production applications is a really intriguing feature
of meteor.

I'll bet something similar could be built if someone was using react and
redux. Sort of like the local development hot reloading with react-transform-
hmr, but running in production. This would make it automatic instead of
requiring a browser reload and erasing the users current ui state. The trick
would be in optimizing the performance. Using a websocket instead of polling
would be a bit more efficient too.

~~~
hankeypancake
Agree on all points. We don't automatically reload the browser though, so it's
up to the user to actually get the new version, otherwise people would be very
angry with us..

The main reason we did it this way, is that it is really really simple and
quick to implement.

Thanks for the input!

------
takno
Does anybody have any good solution to this when caching offline services
through a service worker? Obviously in this scenario even a page refresh
doesn't help.

------
ChemicalWarfare
Sounds like a workable solution.

That said, the way I would've architected this is I'd include a build version
# into the distro and provided a checkVersion backend service that would
return the current build version # for the client side logic to compare it's
build # to.

And if you want to go an extra mile maybe a shouldRefresh service that would
only return "true" if the changes that were made require a refresh on the
client side.

~~~
hankeypancake
That crossed my mind as well. Though, that would require both frontend and
backend code. This takes around 20-40 lines of javascript and works exactly as
intended, and doesn't require maintenance in two or more different places

------
lossolo
Or you could use framework like for example ember.js and have it out of the
box.

~~~
mappu
How does ember.js solve this problem?

------
th0br0
Why not simply edit the HTML5 appcache manifest? (i.e. add a commented-out
timestamp)

~~~
hankeypancake
I'm not very familiar with appcache, but reading a bit about the specifics it
looks like it would work fine as long as you don't need IE<=9 support. Thanks
for the input!

