CThere's other CF products you use instead via bindings, such as KV or R2
Cor D1
Cdepends a lot on what region you make your r2 bucket in
C..and where your worker is running
Ei thought its all "edge"
Cyes but no
Clol, your r2 bucket exists in a specific region and only stays in that region
Cyou can throw CDN on top via R2 Custom Domains and cache stuff on edge/anywhere
E:pepethink:
Esame with workers?
CWorkers run everywhere
E:pepethink:
Cregion: Global
Unless you turn on smart placement or something, they'll always run in the same cf location, close to the user, as the user is routed to
Unless you turn on smart placement or something, they'll always run in the same cf location, close to the user, as the user is routed to
Ewhat about cloudflare pages
CPages Functions are just Workers under the hood, Pages Assets are stored with KV, which exists in two central locations and then is cached on edge. Same for Workers Static Assets
E:pepethink:
Ethank you for this valuable information
Ei will be back for more
Eso whats the latency like with KV or R2 with workers in the same region?
SHow does CF cname flattening work with CF proxying and workers?
If I flatten a cname will my worker never trigger because the response the DNS gives will cause the request to just skip cloudflares network?
If I flatten a cname will my worker never trigger because the response the DNS gives will cause the request to just skip cloudflares network?
CR2 can be pretty quick, it's not the most consistent performance though. I think ~100ms or so uncached to R2, like EWR/ORD to ENAM bucket on average is around that. Just using workers binding and not cache.
If you use cache, either with r2 custom domain or cache binding, of course gets super quick, like under 40-50ms from all locations as long as you hit cache
KV is more complex. You don't have region control, the two central stores are always EU/US. Cached it's great, espec after recent perf changes, maybe knock off 10ms from what r2 cached would be. Uncached is more complex since no region control.
They both serve very different purposes though, KV is eventually consistent, infrequent updates, lots of writes, R2 is strongly consistent, more mixed usage
If you use cache, either with r2 custom domain or cache binding, of course gets super quick, like under 40-50ms from all locations as long as you hit cache
KV is more complex. You don't have region control, the two central stores are always EU/US. Cached it's great, espec after recent perf changes, maybe knock off 10ms from what r2 cached would be. Uncached is more complex since no region control.
They both serve very different purposes though, KV is eventually consistent, infrequent updates, lots of writes, R2 is strongly consistent, more mixed usage
CWorker Custom Domains or Routes?
Cwell -- you can't modify custom domains regardless afaik, and enabling flattening on proxied records wouldn't do anything
E40-50 :pepethink:
Sah ya.. I guess it would not work because a the cname would just get replaced by a cname for the worker 
CI'm counting end to end from my perf monitoring, from the worker it's only going to be ~10ms or so I'd imagine
Cerr actually I think I have that data lol
E10 ms :pepethink:
FAs far as I understand CNAME flattening only remove intermediary CNAME pointer records and the CF nameservers respond directly with A/AAAA records?
Cyes which happens anyway when proxied
Sroutes don't cause a cname to be applied, only custom domains ya?
Eu would be an absolute life saver if u do
Cr2 cached, timing in worker
Ehow big is your data?
Ethe file you requested
C10kb
E:pepethink:
CI don't think size is too much of a factor though, once you get it streaming -- it well streams back at pretty decent speeds
Cr2 uncached from enam region to enam bucket
CKV's pretty solid
S@Chaika sorry I confused myself but to be clear, a CNAME that is proxied and flattened can or can not be intercepted by a worker with a route setup to catch something on that cname/subdomain?
Cflattening shouldn't matter at all, not even sure why it shows up on proxied records currently
CProxy inherently needs to unflatten it to connect, as the client sure can't
CSo the answer is yes* as long as you're not CNAMEing to a CF for SaaS partner on the legacy integration like Shopify
Ebeautiful
Emight have to resort to KV
Ehow long is it presistent for in memory
Cas long as it's getting frequent requests but it's complex in reality
CWorkers run on the same edge machine which handled your original request. There is no affinity to routing to a specific machine which already has your worker running. There is keepalive. Chance of two random connections hitting the same machine and thus getting the same worker is pretty low, espec when it can be any machine at any cf pop. However, keepalive can make it confusing since your browser would keep hitting the same
CIf you're worried about cold starts, CF does a good job of that, taking advantage of the tls handshake to warm up the worker during initial connection, elimating cold starts unless you've got a big worker/a lot of code in global scope
