not normal cache, it'd just be kv. Still correct to say there's no cache before Workers
not normal cache, it'd just be kv. Still correct to say there's no cache before Workers
HThank you. Svelte 5 is a total rewrite of Svelte 4 but is supposed to be backward compatible. However, Svelte 4 is being gently discouraged. Just trying to avoid writing obsolete code from day 1.
AI think you can argue this both ways. If we look at how things were before - there was no cache, all requests hit the worker - that’s not quite true now. There is another mechanism now, with static assets, that means your worker won’t be hit. Whether it’s KV or otherwise is an implementation detail, imo.
CYou can say not all requests will result in worker invocations sure, still no cache though
Cif you wanted to be more specific you could say no cache of worker results but ehh the fact KV internally talks to cache service is an implementation detail
AThat’s fair, I think this is probably a Cloudflare-specific case where it’s a little cloudy (excuse the pun) - as if I was storing something in KV as part of my Worker, I’d say KV is caching, same as Redis in a non-CF architecture. But with CF having so many caching mechanisms, perhaps it’s better to be explicit and say KV rather than cache for Static Asset workers - thanks for the chat, fun to discuss these things
CI mean to me the root of it is just that even if you use kv in your worker you can't cache your worker result and avoid an invocation. Static Assets are entirely free, kv cache hit or not
Cnot possible via binding atm although it's been requested a fair few times
AI agree, but it's not the same as it was before - before it was all workers, every single request, and that's just the distinction that I think is important/needs to be clear. KV, imo, is a form of cache, so I think it's fair to say that for static assets, they are not invoking your worker, and they are (potentially) being returned from cache (which is KV, so you can't control the cache unlike other cache products). What I was getting at with the cache stuff is within Cloudflare specifically there's a lot of heavy-lifting done by the word cache (tiered, reserve etc.) versus in general software engineering, it's a pretty generic term (e.g. you could cache in memory and you're caching, in say a Rails app)
Cyea it's def not same as before. With Pages you could even cache function results (or double cache static) on custom domain if you wanted as well which was interesting
AI think there used to be a diagram somewhere but I can't find it that explained all the caches, where they sit, and the order of execution - maybe it was on a blog. If someone has an up-to-date version of that, that'd be mega handy (including this new stuff with static assets workers)
Cexplained all the caches?
CThere's general request flow chart but I've never seen anything about all the caches I don't think
AMaybe I dreamt it 
Creally not that many anyway unless you want to try to get deep into dns cache/workers being kept warm/etc
ADo you have a link to that general request flow chart by chance?
Cright side of specific dash pages like waf if you have big enough of a screen
AThank you 
Chttps://blog.cloudflare.com/building-cloudflare-on-cloudflare/ there is some other diagrams from blogs like
Coh actually there is flow charts for the tiered caches https://blog.cloudflare.com/introducing-cache-reserve/, if you want to include all of the different types of the normal http caches it gets more complex, like
Local -> Tiered Cache Middle -> Tiered Cache Upper -> Cache Reserve -> Origin
and then if you want to get really complex I believe Cache Reserve lives in Pingora while local (and maybe tiered cache too?) just live in other more local services, one of the reasons why cache api is local only afaik
Local -> Tiered Cache Middle -> Tiered Cache Upper -> Cache Reserve -> Origin
and then if you want to get really complex I believe Cache Reserve lives in Pingora while local (and maybe tiered cache too?) just live in other more local services, one of the reasons why cache api is local only afaik
AThis is awesome, thank you!
Cyea there is a lot of layers of http cache, and the rest is more messy. KV is local/tiered. Workers Cache API is just local. R2 Custom Domains just local too, probably same thing for Pages Custom Domains but I've never checked
Cyea might just be a general cf for saas thing
Dany chance someone can take a look at this? it was reported before and a fix was deployed so not sure why i am experiencing this issue
workers-and-pages-helpError on remote worker: APIError: A request to the Cloudflare API
workers-and-pages-helpError on remote worker: APIError: A request to the Cloudflare API
Ois there a way to get 1 worker to run on GET requests and another worker to run other methods? (not via custom routes either)
Oty
RHi all, I'm using workers and would like to work around the "Simultaneous outgoing
connections/request" limit. Am I able to invoke another worker via service bindings to fan out the requests across multiple workers?
connections/request" limit. Am I able to invoke another worker via service bindings to fan out the requests across multiple workers?
CYou can not.
From https://developers.cloudflare.com/workers/platform/limits/#simultaneous-open-connections
From https://developers.cloudflare.com/workers/platform/limits/#simultaneous-open-connections
Simultaneous Open Connections are measured from the top-level request, meaning any connections open from Workers sharing resources (for example, Workers triggered via Service bindings) will share the simultaneous open connection limit.
RI submitted a request to raise my limit, but never heard back. Has anyone had success in lifting this limit?
CI'd imagine not.
II believe (not completely sure but highly likely) that the limit is Cloudflare-wide, meaning it's an underlying limit that is built into the Workers runtime and not a limit that can be easily increased per customer.
IUnless you have an Enterprise contract that specially permits them, containerized apps aren't currently available for Workers.
IThe blog post was more a "here's this internal thing we're testing out now that might eventually come to external customers" and less "you can deploy containers to Workers right now"
BFeel I've searched and there's different responses and levels of understanding on cache reserve and tiered caching, especially when workers are considered so I just want to clarify
If I am serving a SSR site with workers and static assets, would the following occur;
If I am serving a SSR site with workers and static assets, would the following occur;
- I cache HTML via origin headers (Astro.header.set) on a short TTL, 15 minutes for example. Would tiered caching ever be utilised here if it was switched on?
- If I switch on cache reserve, would the static assets served from the public and _astro directories ever be served from it?
OHow can I acess KV from Cron worker?
ScheduleContext seem to be missing kv fieldOoh nvm, via Env
FIs there some timeline on when Workflows might launch? Is it more weeks or months away? I was hoping this would be launched during launch week but sadly no 
AAnyone using Zig to run Workers with WASM? 
MIs it possible to add some kind of context variable when making RPC calls so that I can consume that from within the
WorkerEntrypoint methods? I'm trying to avoid having to pass context variable into every method in the WorkerEntrypoint.
Wcan someone suggest me a good library for loggers like pino but which will work on cloudflare workers/pages
JIs it possible to add a
tower_http::trace::TraceLayer to a worker somehow? In normal non-wasm axum I'd just add .layer(ServiceBuilder::new().trace_for_http()), but when running with cloudflare I get the unhelpful (seemingly impossible to debug) error:J(I say impossible because the stacktrace points at a minimized file)
