what should the cache header look like? 🤔
what 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?
MEverything is versioned.
Dif my understanding is correct, it doesn't replace the assets, but rather the mapping between paths and KV entries, so an entry is only ever written to once
Vi see, my question was more about the latency / cache invalidation part, which I still don't really understand. Is there another database used for the mappings and if no how can kv instantly serve the old mappings?
KIt's unrelated to KV, really.
KIt's just how Pages has used KV - they have a mapping of
filename => asset and they can just update that mapping, since the old files are there for handling assets that no-longer exist in a new deployment (i.e users have a cached index.html pointing to an old JS bundle) and then the rollbacks just use an older deployment mapping.Cwhy not a todo app?
