Provide an optional CDN resource for web applications with static assets

[sawyerh]

Web applications include static assets (images, fonts, css, client-side JS bundles) and can also include static HTML pages. A CDN, like Cloudfront, provides a caching layer that can improve the performance and scaleability of these web applications. It could be helpful if the Infra template provided a quick way to setup a CDN on a project.

Technical design

Proposed design

• add a has_cdn to app-config
• add a new terraform module infra/modules/cdn
• call the new cdn module from the infra/app/service module if app_config.has_cdn is true
• will also need to update infra/modules/service's outputs to provide values that will be needed to pass into the cdn

Can reference a variation of this approach here.

Alternatives considered

• put the cdn resource directly into infra/modules/service — this adds complexity to the service module and is not relevant for some services, such as API services.

Testing

• use one of platform-test, platform-test-nextjs, or platform-test-flask for testing

Release management

• once the infra template has been updated, we'll want to roll out the cdn to some combination of platform-test, platform-test-nextjs, and platform-test-flask. we could probably leave out platform-test-flask since the flask template is usually used for APIs which don't need CDNs. we can also consider leaving out platform-test to make the ci-infra-service workflow run faster, if we consider breaking the CDN relatively low risk.

[sawyerh]

cc @daphnegold @SammySteiner @acouch in case y'all go this route on your project

[lorenyu]

@sawyerh thanks sawyer. added my thoughts on technical design

[sawyerh]

I implemented most of this today on a project. I did it quickly so probably room for improvement, but hopefully a useful starting point

[lorenyu]

awesome! might need to pick your brain later to see how it works and what we can use.

some initial questions:

• is it best practice these days to push static assets to s3 and then put the cdn in front of it? for my own understanding, is it also common to have the cdn pull from the server directly, or is that not ideal due to cache stampede issues?
• right now i see assets pulling from cdn domain. is the idea that eventually if we want to use a custom domain that the assets would be served from that domain, or would we keep the cdn domain?

[sawyerh]

@lorenyu Good questions.

is it best practice these days to push static assets to s3 and then put the cdn in front of it? for my own understanding, is it also common to have the cdn pull from the server directly, or is that not ideal due to cache stampede issues?

I initially had the S3 bucket because I couldn't figure out how to get Django to serve the static assets but finally figured that out. In the latest changes on the repo I linked, the S3 bucket is no longer part of the infra. I think having the CDN pull from the server directly seems fine but I haven't researched it too deeply. Seems fine if it is a relatively long cache.

is the idea that eventually if we want to use a custom domain that the assets would be served from that domain, or would we keep the cdn domain?

I think using the default Cloudfront domain would suffice for the template and most teams could get away with just using the default. A custom domain would be useful is if it's a static site and you are also putting the static site behind Cloudfront.