fix: minimal guide for static assets #13
Conversation
|
maybe it is good to have some item/section about webpack |
|
Great idea. Do you want to create issue? |
|
@mhdawson I'm really worried about couple PR's in the repo that are hanging out there for a whi Is it ok to get this one landed? It really covers 100% on what we already discussed on the calls and it can be improved. |
wtrocki
force-pushed
the
static-resources
branch
from
a48787a to
65e6ef5
Compare
|
@wtrocki we have a meeting tomorrow and this is top of the list to go through with the rest of the team so I was thinking we'd discuss there and be in a good position to land. Does that work ? |
|
Sounds like good plan! Thank you |
Co-authored-by: Carlos Santana <[email protected]>
| ### Caching | ||
|
|
||
| The static middleware does server-side caching. | ||
| It lets you do two methods of client-side caching: ETag and Max-Age |
There was a problem hiding this comment.
Add reference to https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching
| every modification in your code will be creating resources with different file name. | ||
|
|
||
| When using bundlers you will explicitly need to generate different file names every time content changes. | ||
| Example for webpack (most popular bundler) can be found here: |
There was a problem hiding this comment.
Could mention if hash is used in filename, max age could be as long as a year.
| ### Caching | ||
|
|
||
| The static middleware does server-side caching. | ||
| It lets you do two methods of client-side caching: ETag and Max-Age |
There was a problem hiding this comment.
Cover only max-age - we need to change default argument.
Reference spec: http://expressjs.com/en/resources/middleware/serve-static.html
|
|
||
| The static middleware does server-side caching. | ||
| It lets you do two methods of client-side caching: ETag and Max-Age | ||
| If you configured your static middleware to use client side caching please make sure that |
There was a problem hiding this comment.
We need that differentiated.
|
|
||
| The static middleware does server-side caching. | ||
| It lets you do two methods of client-side caching: ETag and Max-Age | ||
| If you configured your static middleware to use client side caching please make sure that |
There was a problem hiding this comment.
Mention that ETag is not required. CacheControl only.
Disable ETAG.
ETAG - difference between usages. We need to dig deeper why not reliable.
There was a problem hiding this comment.
There was a problem hiding this comment.
There was a problem hiding this comment.
There was a problem hiding this comment.
https://www.freecodecamp.org/news/an-in-depth-introduction-to-http-caching-cache-control-vary/ reference for images and decision/sequence diagrams
| When using express.static() method, we can server static resources directly by specifying the folder name where we have stored our static resources. | ||
|
|
||
| Documentation for the middleware can be found in: | ||
| https://expressjs.com/en/starter/static-files.html |
There was a problem hiding this comment.
Additional guidance for why or why not to serve assets out of application
Serving assets out of application
- Makes application docker images self serving of dependencies (no need to deploy/sync assets to S3 to have application running)
- No need for dedicate step to sync assets (less devops headache)
- No need for application code to hard code domain path for dedicated static assets domain
- Allows relative path for assets for ease of portability
- DeployReviews could go straight to production (since docker images are self serving, these are not dependent on external resources like S3)
- Misconception: Assets do not bloat the docker image as they are small in comparison to poorly written docker images which do not appropriately remove unused code. Eg docker node-alpine image vs node.)
- Assets will already be fronted by Akamai CDN and incur less of a hit to origin.
- Sabotages h2 push (not able to utilize h2 due to separate domain)
Serving assets out of S3
- Has benefit of not incurring application origin hit cost
- Although static assets would still be fronted by Akamai CDN
- Has issues syncing assets from environment to environment
- COS migration is harder as application is dependent on specific buckets/domain names for where assets will live.
- Deploying to specific COS buckets means specific secret and access keys per bucket
- Deploying to specific COS buckets also means associated akamai rules per bucket
There was a problem hiding this comment.
@roastlechon knowing how much effort you have put I would not feel good to apply this change myself. I think it will be the best if you take this over and apply this change directly. Simply because this is exactly what we talked about and I would not say it better.
There was a problem hiding this comment.
i can pull your branch and create new PR if that would be okay by you. I can reference existing comments/feedback in the new PR, while you focus more on the other PRs (graphql)
There was a problem hiding this comment.
Anything you will like. Really I haven't done much and amount of knowledge you have brought here is amazing. Feel free to create new PR, close this one - anything that will minimize hassle on your side
|
You can use this link as a central place for Caching headers https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#Caching |
| It lets you do two methods of client-side caching: ETag and Max-Age | ||
| If you configured your static middleware to use client side caching please make sure that | ||
| every modification in your code will be creating resources with different file name. | ||
|
|
There was a problem hiding this comment.
TODO for me to add section about middlelayers to server (nginx, apache, varnish, cdns, etc)
|
Continued guidance here #39 |
The motivation here is to provide a minimal guide for serving static resources that covered all the issues that we have seen in development. We can merge/adjust this guide and build on top of it with more sophisticated use cases.