CloudFront & S3 for static site hosting

[thewillhuang]

• cheaper (maybe?)
• no use of lambda calls
• no cold starts, website responds faster!
• no 6mb size limit

[tj]

dup of #62. I'd like to put CF infront of Lambda though so you can just utilize http caching for assets (with dynamic apps as well). Currently AWS isn't capable of a great static site hosting since you need to manually invalidate files from CF, but hopefully that'll improve, it's pretty far behind other CDNs in that aspect

[tj]

Actuallllly I'll re-open since the S3 implementation would be different

[thewillhuang]

awesome! thank you 👍

[stephanschubert]

Would love to see that feature—ran into the size limit too a few days ago.

This would also solve https://github.com/apex/up-examples/issues/2 (deploying a Gatsby site).

[Prinzhorn]

I'd love to see the following that I've done semi-manually in the past which also solves the issue with invalidations and a bunch of others:

up will deploy static files (e.g. from /public) to S3 with CloudFront in front and it will also deploy the dynamic application to lambda. Now here's the twist: I've always deployed my apps with a STATIC_FILES_VERSION env variable. So when I made a deployment I incremented the number and pushed the static files into S3 prefixed with the version. E.g. /14/css/style.css. After the static files have been deployed I deployed the application and updated the STATIC_FILES_VERSION env variable. This turned out to be the best thing ever:

1. No need for cache busting using stupid tricks like style.css?13234523445 or answering support tickets with "have you tried clearing your cache?"
2. Clean semantic URL (query strings aren't CDN friendly anyway)
3. You get rollback capabilities for your static assets for free 😱

Instead of incrementing a number up could use the same identifier it already uses to identify different lambda deployments. It could fully transparently handle static files and rollbacks that way. In my pug templates I always have a helper for static files that basically concat STATIC_FILES_ENDPOINT and STATIC_FILES_VERSION. up could provide similar info to the application using env variables.

I don't want to built this my own on top of up but I also don't want to deploy static assets to Lambda

[thewillhuang]

an easier way would be to just hash the file contents and have that as a manifest

[Prinzhorn]

an easier way would be to just hash the file contents and have that as a manifest

@thewillhuang could you elaborate? What would the manifest contain exactly? How does this compare to what I suggested?

If you're using up pro you can likely implement what I've described above using predeploy which combines up env get, up env set and aws s3 cp --recursive public s3://your-bucket...

[edlefebvre]

@tj any news on this feature?

[tj]

@edlefebvre to be honest I'm not making nearly enough to justify adding new features to Up unfortunately, it was worth a try but didn't really work out financially

[edlefebvre]

Oh OK, sorry to hear that. Does it mean you will stop maintaining this repo entirely?

[tj]

Nope! I'll still maintain it, maybe add the small feature here and there, but nothing huge.

[edlefebvre]

OK, thank you for your answer :)

[kaihendry]

I've been successfully orchestrating static sites with https://github.com/aws-samples/aws-cdk-examples/tree/master/typescript/static-site/

[edlefebvre]

Thank you @kaihendry, I will have a look.