Cache Control in Remix Loaders
Vložit
- čas přidán 28. 06. 2024
- Learn how to easily optimize subsequent requests to the same page by adding a Cache Control headers to Remix Loaders.
Play with this demo 👉 remix-movies.pages.dev/
Checkout the code 👉 github.com/remix-run/example-...
00:00 - Navigations with cache control
01:28 - Adding Cache Control to the Loader
03:10 - Previewing the site with Cache Control
Learn more at remix.run - Věda a technologie
Dude... I'm building a SaaS MVP with Remix and it's like every time I have a question or hit a wall you post a new video answering the EXACT thing that I'm struggling with, answering it simply and sweetly. Thank you so much for these videos! 🙌
Can you make a tutorial about the best practice for filtering and pagination for admin pages?
where is the asset stored when cached? in the filesystem? db is not hit but server still needs to retrieve it from somewhere. where is it being fetched from?
These are some lovely patterns, using the web standards wherever possible.
P.S.: For max-age, N is definitely seconds and not minutes. I think you got that mixed up so you got so confused?
Will this continue to work with the single fetch proposal?
What if some loaders on the route return user data but others return static content like here. Would the cache control header get applied to the entire response?
Using user data as an example as I was thinking from a CDN cache layer.
But for a local browser cache even I’d be worried about stale data from other loaders.
If you wanted to invalidate the cache before the expiration time, u could do it with sse? Maybe sending a event to the client and telling it to revalidate the data? And with that caching new data for the other users with the cache layer?
You can use a very short `max-age` in addition to a longer `stale-while-revalidate`, so the browser and/or cache server, proxy server, CDN, etc will answer instantaneously with the cached response, while refetching in parallel a fresh version for the next visitor or request. :)
if it is stored in the browser then the request from the next user fetching that data will still need to hit the db because second user doesn't have access to the browser of the first user?
Agree, the way it's described in this video is misleading! Saying that - in this example the cache control was set to public, so if the URL was fronted by a properly configured CDN or other caching layer, it could be cached in there and speed up the next request for other users too.
When using Cache-Control the cache is stored in the browser and/or any proxy (like a CDN) in the middle, this is all customizable using the max-age and s-maxage directives on the header, if only cached in a browser then yes a second user will need to hit the server again, but if cached in a CDN it will be shared between users
He discussed how this can be used on the CDN layer @5:12
I'm still discovering Remix theorically so probably i'll discover the answer to this, but for now, I'm wondering, I thought the loader data was streamed with everything else, but it looks like not in your example.
If it is streamed, sometimes, so shared between many loaders / pages, how would the cache headers apply to the global response ?
Thx
when I do this, I never see the size coming from the disk (around 3:02 in the video). Is this due to being in localdev?
atm machine