yeah I saw that, but it doesn't really help with the practical differences regarding CF's cache impl
yeah I saw that, but it doesn't really help with the practical differences regarding CF's cache impl. + purging
RMight be worth updating the docs here https://developers.cloudflare.com/workers/reference/how-the-cache-works/#purge-assets-stored-with-the-cache-api to mention some of that applies to
cache.openCloudflare Docs
How Workers interacts with the Cloudflare cache.
HIf it makes a difference, the Cache API doesn't validate that the domains of the URLs you pass in exist. So you could just make up a fake domain to create different cache spaces
Rha interesting. It's a really funny API to work with tbh. Kinda dancing around http even though a lot of use cases would be simpler by just passing a string as the cache key.
Rout of interest, are cache entries written via the Cache API considered part of the zone the worker is running on or is it the zone of the url being cached?
Re.g.. worker on foo.com caches something under bar.com
HThe zone of the Worker. You can cache a
cloudflare.comcloudflare.comWould be very bad if you could mess with other people's caches that way...
RYeah that's what I was thinking, although this flow chart had me worried https://developers.cloudflare.com/workers/reference/how-the-cache-works/#single-file-purge--assets-cached-by-a-worker
Cloudflare Docs
How Workers interacts with the Cloudflare cache.
R(we're caching API calls to shopify which I know is also on CF)
Rbut I guess that's actually specific to the ability to single-file purge, i.e. because shopify is on CF then we can't single file purge, as they own that... but maybe we should just change it to be cached under
https://{uuid}.comhttps://domain-we-own.comAlthough still worrying to think the owner (shopify) can purge our cache entries "Sorry, you can not purge the asset. Only the owner of notexample.com can purge it"
HYou could also use
https://shopify.com.richa.rd/somePathbut what if
.rdNo, I meant put it on a non-existent subdomain of your domain
HSince you own it, then only you could break it
HI was just using
richa.rdah right, got you. Yes I think that sounds like the safest bet
RAlso, even if I switched it out for our domain, I'd still need to use
caches.default
LHi everyone
LIm trying to make Inserts in my D1 Database and i would like to recieve de surrogated key of each insert i make, but it looks like line 42 does not return this new ID
Ldoes someone know how to fix this?
Ddoes CF Cache just use KV?
Dcurios as to how it’s so fast
Ddoes it use the priority latency that you get when you pay for workers instead of the free plan?
CWhich cache? The Cache API? The Cache API is entirely colo/datacenter local, evicting assets based on access frequency
Cplan shouldn't matter
Djust saw a “always lowest latency” or something along those lines. the cache has a 8ms time where as my hono api with a hello world json at the base route takes 30
Djust curious as to what makes such a difference
Di believe so, the one that caches based upon headers which requires a custom domain
Csounds like you're talking about the normal cf cache (not in front of a worker/in a worker, in front of a normal origin), vs workers executing?
Dyea that sounds right. Sorry, not familiar with the workers side of cf
CI was just asking because the opposite is expected, and CF has publicly stated before Workers are cheaper for them (as in, less latency, as cache is spread out through the DC, but Workers can run right there) then Cache hits are. For me a simple worker returning html is ~50-55ms, and cache is somewhere between ~50-60ms
Dinteresting, not too sure why that’s happening then
Cdo you have smart placement enabled or anything?
Dpossibly i’m close to a Cache data center? it’s a dramatic difference
Di do but last i checked it said i didn’t have enough data
Call DCs can execute Workers, same as all can do Cache
Ccheck the cf-placement response header
Dcf-placement: local-ORD
D
DIm currently comparing my latency to a service like unkey where their latency is dramatically lower, both of us use cf workers
CDoes the Cf-Ray response header for both return the same location?
DJust ran on a different endpoint (195ms-> 5ms) and it has the exact same cf-ray
Cbased on that header count it looks like they're both workers, but you're saying one uses cache and the other one doesn't, or am I misunderstanding?
C(I would make sure to send a handful of requests as well to make sure the connection and everything is warm before looking at the response, REST clients don't make the best benchmarking tools)
DIm really just curious how I can get my latency down lower, a endpoint with nearly 0 extra computation ontop of hono takes 3x as long to execute
Dah, did not think about that. let me push without a cache and check the numbers
DSemi related, hows the experience with KV / D1 for a db and ratelimiting? Currently using turso and upstash and the latency is pretty high
CKV <- uncached two central stores, cached is still ~20-30ms slower then normal cf cache/workers
D1 -> single location for now, only in Durable Object supported locations as well
For Rate limiting, there is a binding you can use in Workers now to use that colo's/dc's normal ratelimiting
D1 -> single location for now, only in Durable Object supported locations as well
For Rate limiting, there is a binding you can use in Workers now to use that colo's/dc's normal ratelimiting
Cah I'm just a bit confused on exactly what you are comparing. If it helps, here's a simple worker with Enterprise routing that returns the url requested: https://quick-test.workers.tylerobrien.dev/, no cache or anything