#CDN Caching of Remix on Cloudflare pages

1 messages · Page 1 of 1 (latest)

past loom
#

I was watching the Remix video on CDN Caching (https://youtu.be/bfLFHp7Sbkg) and find it super interesting, but since we host all our Remix apps on Cloudflare Pages, I believe this doesn't work for us? Since Pages run on Workers and Workers are executed in front of the cache, not behind it.

Are there any other ways of achieving this, except calling the Cloudflare Cache ourselves in the code? We wouldn't be able to make use of the stale-while-revalidate feature, but could still cache requests to external data sources.

An alternative would be to migrate the hosting to AWS Lambda and use Cloudflare as CDN, but I really love Cloudflare Pages.

Remix relies on CDNs and cache control headers to get the best web performance possible. Here we’ll compare various caching strategies, including Static Site Generation and Increment Static Regeneration, and compare the tradeoffs.

▶ Play video
unreal girder
#

Apparently you can run Workers after the cache
Since Cloudflare Workers can run before, and after the cache, a Worker can also be utilized to modify assets once they are returned from the cache, to sign or personalize responses, while reducing load on an origin, or latency to the end user by serving assets from a nearby location.
https://developers.cloudflare.com/workers/learning/how-the-cache-works/

Workers was designed and built on top of Cloudflare’s edge network to allow developers to interact directly with the Cloudflare cache. The cache can provide …

past loom
past loom
#

But thanks for sharing! Don’t get me wrong 😁

wary viper
#

You're right, you can't run "after the cache" with a worker (which is what remix runs on in cloudflare pages). All requests hit the worker first

#

With cloudflare pages and remix your static assets are cached behind a CDN, no worker is involved there

#

If you want to cache the entire remix response, you can integrate the Cache API in your fetch handler before the request goes through remix

#

I would caution against this without measuring it tho, remix being a dynamic system it's easy to serve stale content this way

#

I don't have time to watch that whole video, can you point to a timestamp you're referencing in this question?

unreal girder
wary viper
past loom
past loom
unreal girder
small bobcat
#

I think static assets are stored in KV and then cached in the CDN, right?
I don't believe so. KV and the caches.default cache are different stores. KV can hold any string, but is relatively expensive. The response cache can only cache HTTP responses, but is much cheaper.
https://developers.cloudflare.com/workers/runtime-apis/kv/
https://developers.cloudflare.com/workers/runtime-apis/cache/

Workers KV is a global, low-latency, key-value data store. It stores data in a small number of centralized data centers, then caches that data in …

The Cache API allows fine grained control of reading and writing from the Cloudflare edge network cache.

wary viper
#

KV does make a lot of sense there

daring rapids
#

I've been attempting to deploy a Remix application on Cloudflare Pages, but I'm encountering issues with the caching behaviour. Specifically, the caching is not functioning as expected based on the cache headers I've set.

Based on the discussions in this thread, it appears that the issue might be due to Cloudflare's own caching mechanisms. Additionally, it seems that every incoming request is initially processed by a Cloudflare Worker can also be the reason.

Is that correct?

For reference, I'm using the following header configuration:

export const headers: HeadersFunction = ({ loaderHeaders }) => ({
  "Cache-Control": loaderHeaders.get("Cache-Control") || "public, max-age=60",
});

Btw, this header configuration works as expected when I deploy the application on other platforms like Vercel.