I have a React/redux app which is deployed on CloudFront + s3. There is no static hosting enabled on the bucket. I understand that invalidating cache on a new deployment clears cache in all the edge locations and the new changes will be served up. But what happens to the active prod users when the cache is invalidated? Are they able to continue on the app without any errors? Does it get worse for the active users if the redux store structure changed in the new version?
Clearing the cloudfront cache will bring up the fresh content from your origin. However, that would not affect the existing production users. They would continue to be served from the cached content as long as their session continues.
That being said, they would be served the fresh content when their session restarts.
There would be no errors whatsoever.
Hope this helps.
I've been wondering the same thing for my React website, which is made up of many chunks. I wouldn't worry about your Redux state unless you're saving it to cookie/localstorage and loading it again. In that case you could write some migration check during loading. Or even have it versioned in some way.
Regarding caching, I don't recommend deleting any files for up to a year. That way your active users would still be able to download chunks while they're active on your website.
During deployment I upload all the new files and clear the cache on all *.html files to get the latest reference to js and css files.
Related
Our site is being made available with the following structure:
Static Blob Container Azure > CDN > Cloudflare > User.
The React app build is made available in an Azure Static Blob Container that is accessed by an Azure CDN. When we access the app via the CDN URL, we never have a cache problem. We also use cloudflare to manage the DNS and supposedly improve the cache. But when we access the app through cloudflare, we have a serious cache problem, returning extremely old versions for users who have accessed the site before.
Even after turning off all cache options available in Cloudflare's dashboard and its graphics show that cache consumption has dropped, the bug still persists. We were unable to identify where our problem is in the structure mentioned above.
The problem is because a CDN uses multiple nodes to serve the content. The proper way to 'solve' this is appending a version in the filename or path, this way, whenever you need to change something, the CDN will download the latest version. Just using a regular 'app.js' is not enough.
More info:
How to force the browser to reload cached CSS and JavaScript files
https://stackoverflow.com/a/34604256/1384539
I want to speed up the initial load of an React/Meteor web page.
One of several Ideas is to cache data. So fare so good...
This was tried with service workers. This was only possible for me under "/public/" folder but in addition I want to cache data from eg. "/client/" for caching more data.
Is this possible to cache more data from other folders?
I did pretty much the same as described here under "Step 1 - Add a service worker ":
https://dev.to/jankapunkt/transform-any-meteor-app-into-a-pwa-4k44
UPDATES:
we are using this Web page only in an intranet without internet connection.
things with React and Meteor don't really work that way.
It is expected to have an up to 1MB JS bundle to deliver to your client. A medium size app should look at 400-500kb of gzipped bundle size.
Don't use the public folder for assets, put everything in a CDN with edge cacheing like the AWS Cloudfront (store in S3 and expose via Cloudfront), or any other storage.
In your CDN you can set the expiry and cache-control (max-age) and this is used by the client (browser) for cacheing assets.
Deliver your JS and CSS bundles from a CDN.
Use split code extensively (ideally at routing level).
Whenever possible use async libraries form maps, players etc instead of NPM (which builds into your bundle).
With a PWA environment you will cache your bundle files not your public folder. The tutorial you followed for PWA is incomplete and useless. It only looks to how to get a green badge in the audit, it does nothing of any use.
One more thing, your Meteor bundle size impacts the traffic on your Meteor server. This is why you better deliver the bundle and all assets from CDN's.
Cacheing more with service workers only leads to flickers, inconsistencies between tabs and browsers, errors.
I just released my react app in a production environment in Cloud Foundry, but the only problem is that if I make changes to the app, and reupload the app, my users don't see the changes unless they clear their browser data, what can I do?
Reason for this issue: Browser is using its cache not your build to serve the client
Remedy to outcome: Inform the changes in metadata.json
metadata.json is a file that swings between request and browser checks for any mismatch with it's cache. if no then cache is served to client.
There are more then one way, thus am not telling direct solution, instead gothrough the below link will take to through various steps to follow
flexdinesh blog from dev.to
I am building a ReactJS app using create-react-app build, and deploying to Amazon S3 and CloudFront. Deploying is easy enough; when I create a new version, I can sync the build directory to S3, hit reload, and everything works well. The index.html contains references to the latest build via unique hash keys, so I always get the latest files.
But what about active users that are using the old version(s) of index.html? Their browsers will reference "chunks" that no longer exist. How should I update to my latest build without disturbing these users?
A blunt solution might be to keep the files from the older builds, but then the user would not be automatically updated to the new version. And cleanup of the old files would be messy.
In my CloudFront setup, when an active user requests a missing chunk, the browser will be directed to index.html for the 404/403 errors. Perhaps the upgrades are already managed automatically, forcing a reload of index.html (and therefore references to the new files)?
I use CloudFront from AWS and I have an S3 static website.
I use ReactJs and I changed some texts on most pages.
The problem I have now is that I use
npm run build
to produce the production application. I want to update the content on AWS in the S3 bucket (I previously uploaded the same files) however two things happen:
-When I access in incognito, everything works fine, I am given the updated version of the website
-When I access in normal mode with web browsers that I used to access the website before, I am still given the old version of files.
I accessed AWS documentation and I have two solutions:
-Wait 24 hours for CloudFront to cache files in edge locations
-Use version name for the files (for example, change the name of image.jpg to image_1.jpg; image_2.jpg etc.)
I would definitely go with the second option which indeed is time consuming but for sure less than 24 hours. Should I change the name of EACH file that I have in build or just those in static?
Any other solutions?
Something I haven't tried is, before uploading to AWS S3, create a folder such as V1 and upload my react files. When I make a change I call the folder V2 and so on.
Using version names is the most robust method. It gives you full control on the cache behavior without messing around with CloudFront.
So yes, each time there's a new version update your file names.
Btw, if you bootstrapped your react app using create-react-app then the build process does that by default. It will name each bundle with a unique hash every time the bundle changes. This way you can utilize long-term cache in the browser and CF for your files.
You'd probably still have to invalidate the root index.html each deployment as its name doesn't change between versions.