Finished porting my website to React Static. Yay! But More importantly, today I setup S3 and Cloudfront to serve the static site under HTTPS.
I would love to say I had it all done in 1 hour, thanks to nice guides like this one: Hosting Static React Websites on AWS S3 (& CloudFront) with SSL . Unfortunately, the AWS experience is not the best so things got complicated a few times.
AWS UX Sucks
Serving the static
posts/index.html page for requests like
/posts/ is trivial for S3 buckets with the website hosting feature enabled. But for yet another unimaginable reason, when you select the S3 origin for your Cloudfront distribution, you need to manually type the "S3 website" endpoint instead of picking the suggested endpoint from the dropdown. Otherwise Cloudfront will always return a 403 with some sexy XML instead of the static page. Go figure.
My initial strategy for keeping staging and production segregated also fell apart. Another step, another bummer, classic AWS experience. This time, this issue (bug?) in S3 + Cloudfront integration does not allow pointing different distributions to same bucket plus path prefixes. Go figure.
To wrap this up, in order to redirect a legacy
andretorgal.com, both under http and https, I followed the official documentation for redirecting dns queries. A simple 7 step process: setup a CNAME in Route 53 pointing to a transparent Cloudfront distribution with an associated SSL certificate and http/https redirection, with origin in an empty S3 bucket with website hosting enabled and, finally, a domain redirection. Out of breath.
Of course, it didn't work. Go figure.
With all the time wasted trying to solve all these puzzles and reconfiguring everything from scratch 3 or 4 times, at this point, the question is why do I insist in staying in AWS at all. Go figure.
Controlling cache with Cloudfront and S3
Another challenge was to decide what to cache and for how long. The site has no service worker, so I'm looking only into caching static html files,
main.css, and the React Static
routeInfo.json files. Since
main.css are hashed with each build, it's ok to load a stale
index.html page here and there, since it will still be able to load the corresponding app version.
The failure mode, in this case, is loading a more recent
routeInfo.json to navigate to another page, and running into a payload that is incompatible with the loaded app version.
Implementing the cache strategy was quite easy, by setting the headers straight in the S3 bucket objects, when syncing build and statics. With the help of this caching best practices guide and this AWS S3 sync gist,
Hopefully, I got this right. But I'm not even going to double check. At this point, I'm just suffering AWS fatigue and want to go back to play with the interesting stuff.
Finally, [configuring robots.txt and meta tags](https://www.polemicdigital.com/protect-your-staging-environment to keep search engines from indexing staging is tricky, and might not work as expected. I'll have to keep an eye on what's being indexed to make sure I don't screw this up.
Need to make sure I keep my Cloudfront bills in check, so compression in cloudfront is top priority.
For now, the entire
dist/ is synced up to S3 in a few seconds. I couldn't be happier with this. But continuous integration and deployment will help focusing more on authoring and experimentation.
Plenty of other features, fixes and tweaks to develop.
And a lot more content.