End-to-end life cycle of caching for an SPA hosted on AWS S3 and Cloudfront
tl;dr: this is an explanation post providing visual diagram for the last three posts from E2E flow perspective — I am a firm believer that a picture is worth 1000 words, and I hope the diagrams can make the steps in previous post more clearly explained.
Why do we choose S3 + Cloudfront as hosting and caching option
For an SPA, the entire front-end is a static bundle of assets, therefore, S3 is a great hosting server because:
S3 is super cheap (literally, AWS won’t charge a penny for the size of your SPA app) — cheap from infrastructure cost perspective;
S3 is super reliable;
(because of the previous point) there is almost no daily maintenance needs — cheap from engineering investment perspective
Cloudfront is easy to use and low maintenance as well, and well integrated with S3 for providing caching solution for S3 assets.
High level diagram about web caching
Mapping of the above picture in the context of AWS S3 + Cloudfront architecture:
S3 is the “web server”
Cloudfront contains the “shared cache”
Browser cache contains the “private cache”
Workflow for the release process
Please see the code of “Using Github Action” section in our previous post.
Cache behavior for browser and Cloudfront
This is a diagram sequence talking about last two post: post 1 and post 2
The first user (in a region) using our react app after the new release is deployed to S3:
The 2nd user (in a region) using our react app after the new release is deployed to S3:
Hopefully, the diagrams above make the previous posts further clear.