Ufdjrw

I expect this applies to any web framework using webpack that builds assets / chunks, in my case it's Vue.

My workflow is:

1. Develop a feature


2. Build (npm run build)


3. Deploy (eb deploy)


4. Back to 1.

Building removes all previous chunks as adds new ones i.e.

my-module.1X3DF23.js

my-other-module.9DFdw232.js

If a user was on the front end at this same time without refreshing the page (SPA, so unlikely) and browses to a new view that depends on a chunk that's been wiped, they get a 404 for those missing old assets.

Until this point, I have been incrementing a version number along with any XHR requests from the server. If the app notices a change, it will reload itself. But if 404 errors are coming up from chunks, no XHR requests will be called anyway.

Initial thoughts:

1. Have the web app ping the back-end with an interval of say 30 seconds, this would trigger the version refreshing automatically.

Any alternatives?

I would go with not deleting previous chunks at all. I don't know how elasticbeanstalk works so I will show you my strategy with a good old ubuntu server.

Basically, you have those folders in your Vue application:

dist -> Contains the content of the built application with npm run build
node_modules
public
src
...

What I do is that I create a new folder named deploy because one problem of the dist folder is that npm run build deletes the content of the dist folder at the beginning of build.

Having the deploy folder, you can keep all the data needed across time.

So when I build my project, I then copy the content of the dist folder into the deploy folder without deleting previous chunks.

In order to avoid the deploy folder to interfere with git, I add it to the .gitignore registry.

You can do this with a simple recursive paste using bash:

cp -R dist/* deploy/

This will replace your index.html page into the deploy folder but will not overwrite your previous chunks.

Problem with this solution: Your deploy folder might get huge because previous chunks would never be deleted.

Solution for this problem: Write a robust script that deletes chunks older than 1 day (or more) when deploying the application. You can base your script on the creation date of the file. If you are fluent with bash, go with it. I personally prefer to write this kind of script with node directly in a deploy.js script at the root of my project..

I would suggest you doing the following

Consider a static URL resource that you serve as follows

abc.com/v1/module.123.js

I would suggest you to keep the

v1

Part as same inbetween your build updates.

Webpack will generate a new file name as follows

build1: module.123.js

build2: module.234.js

whenever the content of module.js changes inbetween your builds.

During your build updates make sure you are not removing your

v1

folder in your server. Rather doing a complete replacement you can merge the old folder and new folder. By doing this you will be having both

module.123.js

module.234.js

in your v1 folder in the server. By doing this you will avoid the http 404 error in the SPA.

You can notify the user of a build update through another process, and asking him to refresh the browser to get the changes. This notification of changes to the user can be done using a Server Sent Event

You can change the V1 folder every 6 months or so to V2 or something else that suits your needs to clean up unused files.

If your application is a 100% static application, you can use AWS S3 bucket. To update you application you just need to update your repo.

aws s3 sync --delete /source /destiny

We have been doing this and the update is seamless as you expect.