Should I use Workers or Pages Functions? I see that Pages and Workers are merging, but I don't know
Should I use Workers or Pages Functions? I see that Pages and Workers are merging, but I don't know which one is going away. Thanks.
AGood to know, that would still mean there is now cache before a worker, technically - I know there’s many levels to caching with reserve / tiered cache etc but before I think there was 0 cache before workers, there’s now at least something that could be hit
APages is merging into Workers, but Pages likely exists for a long time as there’s a lot that uses it I would suspect. To help you choose, there’s a matrix here: https://developers.cloudflare.com/workers/static-assets/compatibility-matrix/ (but there’s no time period for merging etc known yet)
Cloudflare Docs
Compatibility matrix for asset hosting on Cloudflare Workers and Pages.
AYup, but still - my point was just that “workers execute before cache” that used to always be true now has a nuance 
HSo if I am starting a Svelte project, for instance, I should use Workers and the https://github.com/sveltejs/kit/tree/main/packages/adapter-cloudflare-workers instead of the adapter-cloudflare, which is for Pages with Functions.
GitHub
web development, streamlined. Contribute to sveltejs/kit development by creating an account on GitHub.
AMy message got deleted 
But I’d say that’s a good idea (CF docs: https://developers.cloudflare.com/workers/frameworks/framework-guides/svelte/). Keep in mind it is in beta, so maybe some bugs, but as betas go, it’s probably pretty stable.
But I’d say that’s a good idea (CF docs: https://developers.cloudflare.com/workers/frameworks/framework-guides/svelte/). Keep in mind it is in beta, so maybe some bugs, but as betas go, it’s probably pretty stable.HIs there any support for Svelte 5?
AThat I do not know
Cnot 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 
