Dealing with releases of single page applications
1–10 of 13 posts
Re: Dealing with releases of single page applications
#2Sounds 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.
Re: Dealing with releases of single page applications
#3Or you could use framework like for example ember.js and have it out of the box.
Re: Dealing with releases of single page applications
#4Or you could use framework like for example ember.js and have it out of the box.
How does ember.js solve this problem?
Re: Dealing with releases of single page applications
#5If 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
Re: Dealing with releases of single page applications
#6Why not simply edit the HTML5 appcache manifest? (i.e. add a commented-out timestamp)
Re: Dealing with releases of single page applications
#7Does 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.
Re: Dealing with releases of single page applications
#8Sounds 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…
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
Re: Dealing with releases of single page applications
#9If 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
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
Re: Dealing with releases of single page applications
#10Cool 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.