I am using AngularJS 1.5.8 to build the client side of my webapp. I have frequent problems because users don't have the last version of the webapp client side. Is there an easy way to perform hot angular app reloading, in order my users to always have the last version? (I am looking for an alternative of websockets)
You can poll your server from your client web-app by using setInterval() with an ajax call to some REST endpoint that is capable of returning the most recent version. If that version doesn't match, say, your "version" variable, then you force a reload of the application.
In your index.html file where you load in all your .js files, you can include a version number in the URL that you increment whenever you do a new build. This will force the user's browser to reload the library from your server as the URL won't exactly match, effectively breaking the cache mechanism and preventing old versions of your code from loading.
The additional data in the URL won't have any effect on the application otherwise.
<script src="js/app.js?v1.2.3"></script>
<script src="js/services.js?v1.2.3"></script>
<script src="js/filters.js?v1.2.3"></script>
<script src="js/directives.js?v1.2.3"></script>
<script src="js/components.js?v1.2.3"></script>
You would do a search/replace for v1.2.3 to v1.2.4 on the next build.
If you're using something like webpack, or some other build pipeline / automation tool, you can do this automatically by including the hash of the library in the file name, and then dynamically updating the URL in the index.html file. When you see files like app.ad76c09743ef.js, that's likely how that's being generated. This ensures that even a single character change in your source results in a new, unique hash that will prevent the browser from using an older cached value.
The library I have used for this to good success is https://github.com/saintmac/angular-cache-buster
Each time the user makes a request for a resources, it will force latest version it not on white list.
Related
Is there any way to have service workers fetch the cached version, then attempt to do a network fetch, and if it's different than the cached version, put that new thing in the cache and replace the old asset in the DOM with the new one instantly (without having to refresh the page)?
Hey yeah this is a very tricky situation but what I did was save a version number to my .env file on production release.
I then built this NPM package which will surface the Version number of the .env at build time. I could then use this number in my VueJS - PWA to check against the old currently cached version number, and then do a network request if they dont match.
https://www.npmjs.com/package/vue-enverywhere
I have a ReactJS app hosted in S3 and using Cloudflare as DNS & CDN.
I have a huge issue, a lot of visitors have old version of the application stored in their browser cache (index.html only). I have configured advanced cache control in the newest version, but it cannot be accessed because older version is shown instead.
Static file (CSS, JS) versioning is done using create-react-app, but I have discovered that index.html file is the only cached one.
What should I do now?
How to purge visitors cache now?
PS: I have purged Cloudflare cache already and setup rule to bypass cache.
Unfortunately there is no such solution for this.
The only way is to wait until users cache will empty (expire).
It is technicaly impossible to clear users cache from external resource (JS script etc.), due to security reasons.
Also if it will be possible, there is no way how to tell users to download latest JS (including cache purging code), because they have old version of index.html (including link to those .js files).
You are stack and the only option is to wait.
A better approach would be, whenever your build changes, change the JS link so that the browser downloads the new version from the server, no matter the user's or the server's caching policy.
For example, the way Stack Exchange does it is, whenever the build changes, the HTML goes from something like:
<script src="https://cdn.sstatic.net/Js/stub.en.js?v=1bac371ac78f"></script>
to
<script src="https://cdn.sstatic.net/Js/stub.en.js?v=f83b2f654"></script>
Whenever there's a new build, you can randomize the parameter in the query string in the HTML, and still only have the single (most recent) built .js on your server.
Everytime I deploy an update to our web application customers ring in with issues where their browser hasnt picked up that index.html has changed and since the name of the .js file has changed they run into errors. Presumably because their index.html still points to the old javascript file which no longer exists.
What is the correct way to ensure that users always get the latest version when the system is updated.
We have a HTML5 + AngularJS web application. It uses WebPack to bundle the vendor and app javascript into two js files. The files contain a hashname to ensure they are different once released.
Some other information
I can never replicate this issue locally (and by that I mean in debug, on our staging site or our production site)
We use CloudFlare but purge the entire cache after release
We have a mechanism in JS that checks on page load or every 5 minutes to see if the version of our API has changed, and if so show up a "Please refresh your browser" message. Clicking this runs window.location.reload(true);
Our backend is IIS
If you need users to pick up the latest index.html when they load your site immediately after you've updated the file, make index.html non-cacheable. That will mean the browser, CloudFlare, and any intermediate proxies aren't allowed to cache it, and that one file will always be served from your canonical server.
Naturally, that has a traffic and latency impact (for you and them), but if that's really your requirement, I don't see any other option.
There are spins on this. It might not be index.html itself that isn't cacheable, you could insert another resource (a tiny JavaScript file that writes out the correct script tags) if index.html is really big and it's important to cache it, etc. But if you need the change picked up immediately, you'll need a non-cacheable resource that identifies the change.
We have a large number of people (10k+) who return to my clients' sites on a regular basis to use a web app we built, improve, and host for them. We have been making fairly frequent backward-incompatible updates to the web app's javascript as our app has improved and evolved. During deployments, the javascript is minified and concatenated into one file, loaded in the browser by require.js, and is uploaded to and hosted on Amazon S3. The file name & url currently doesn't change at all during updates. This last week we deployed a major refactor to the web app and got a few (but not a lot) of reports back that the app stopped working for some people, particularly in firefox. It seemed like a caching issue. We were able to see it initially in a few browsers in testing but it seemed to go away after a refresh or two.
It dawned on me that I really don't know what browser-caching ramifications deploying a new version of a javascript file (with the same name) on S3 will have and whether this situation warrants cache-busting or manipulating S3's headers or anything. Can someone help me get a handle on this? Are there actions I should be taking during deployments to ensure that browsers will immediately get the new version of a javascript file? If not, we run the risk of the javascript and the server API being out of sync and failing, which I think happened here.
Not sure if it matters, but the site's server runs Django and the app and DB are deployed to Heroku. Static files are deployed to S3 using S3Boto via Django's collectstatic command.
This depends a lot on the behaviour of S3 and the headers it sends when requesting files on S3. As you experienced, browsers will show different caching behaviour - so the best option is to use unique filenames.
I would suggest to use cachebuster hashes - in this way you can be sure that the new file always gets requested by browsers and you can use long cache-lifetime headers if you host the files on your own server.
You can for example create a MD5 hash of your minified file and append it (like mycss-322242fadcd23.css). Or you could use the revision number of your source control system. You have to use the cache buster in all links to this file, but you can normally easily do this in your templates where you embed your static resources. Depending on your application, you could probably use this Django plugin that should do this work for you.
I am currently testing a web site as the development goes on, and almost every time the client script is updated, I need to clear the browser cache for a new functionality to become available on the client due to the fact that the browser downloads the fresh compy of the .js file.
What if in production I roll out a new version of a script? How do I get the client browsers to get it as soon as it is uploaded to the server?
I am using an ASP.NET MVC 4 site.
Easiest way will be adding the version number to the script file(say script_1.6.js etc)
Rename the file to create versioning:
so
<script src="myscript.js"></script>
becomes
<script src="myscript-9-5-2012.js"></script>
Also per https://developers.google.com/speed/docs/best-practices/caching#LeverageProxyCaching
It's not recommended to use querystrings for versioning (ie. myscript.js?v=1.1.0) because specifically
Most proxies, most notably Squid up through version 3.0, do not cache resources with a "?" in their URL ...
The best way to stop your scripts from caching is to add a random querystring value at the end of each line. e.g.
<script src="/path-to-your-script/script.js?v=0b1"></script>
This is great in development as your scripts never get cached, although in production you do really want the browser to cache the scripts to speed things up.
So for production, you would probably want to introduce some versioning like jquery for instance, jquery-1.8.0.js