TTL cache-control is not good imho.
TTL cache-control is not good imho.
CThe image is preprocessed and encoded as base64 when first import.
Also the size is guaranteed to be < 25MB and KV is already available in my app.
Also the size is guaranteed to be < 25MB and KV is already available in my app.
U
why not
CMaybe calculate a hash and then throw redirect and set the cache to forever? 
UI'm very confused... I would just set a cache control header 
Cusing time-out?
UIm not sure what time outs have to do with a header?
Cbecause, the images are serve at
/images/[id]. There was no hash pre-calculated.Cwhat should the cache header look like?
AThis document is a great overview of the different caching options: https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching . The caching headers that you decide use will vary based on your application's use cases. I encourage you to read through the options and test out a few of them, to see what works best.
The HTTP cache stores a response associated with a request and reuses the stored response for subsequent requests.
JRead heavy workloads. Storing assets is a great example
JIt’s also just fine for storing stuff you don’t mind taking 60 seconds to be invalidated. Caches is another great example
JWorkers 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 …
JData is cached in local datacenters after being retrieved once
JWhereas R2 is always in a single location
JKV is also cheaper IIRC
ENah, R2 is slower but cheaper
JAhh fair, thanks for clarification
JI love the simplicity of KV for storing things like assets, and caches personally. Those things might not change for days, weeks, or months, so I just don’t need strong consistency.
JYou can’t put CDN cache in front of a worker. You could use workers cache api but that’s still gonna incur a cold read to R2 which’ll be slower than KV
JSure if you’re just doing that then R2 makes more sense
JReal world example with heavy KV usage; https://playerdb.co
We query dynamically from various APIs and read/write to KV for caching results.
We query dynamically from various APIs and read/write to KV for caching results.
PlayerDB is a JSON powered player fetching and caching service. Lookup player names and IDs for Minecraft, Steam, and Xbox accounts.
ECloudflare Pages is also using KV to serve assets quickly
JPretty much yep
JCache api is datacenter specific (more or less), and prone to being evicted. KV is a permanent store, and globally available
JIn this api, it doesn’t change often. And if it does, it’s something like an avatar which is okay to be a little out of date. We arbitrarily set keys to expire after 7 days if I recall
JMy understanding is within 60 seconds, yes
EAlso assuming you hadn't previously tried to access that key and had the 404 cached
ECorrect
EAt the moment it is
JNot directly, no. You'd have to list, read, and then write keys into your new KV namespace.
C
VHow does instant rollback work on Pages if the whole thing is backed by KV?
