Thank you for answering a bunch of initial questions I had about workers here https://community.cloudflare.com/t/confused-about-workers/93497
Also, to Cloudflare folks, I love Workers. Thank you so much for thinking forward and with such great ideas.
I have more questions. Still a bit confused about some of the decisions behind Workers…
In the Cloudflare Dashboard, we are able to create Scripts, WASM Modules and KV Namespaces that are not associated with any specific domain via Home->Create Worker (can be used by any domain in our account) So far so good. How come when we go to Domain->Workers we are only able to create new Scripts and not WASM Modules or KV Namespaces? Also, when we create a Worker from Home->Create Worker the script associated with it is given a random name that we can’t change whereas when we create a Script from Domain->Workers we get to name it whatever we want.
Why does the REST API have some powerful and much needed features that are missing in the Worker JS API? For example, the REST API allows us to list all keys with prefix, limit and cursor (important for pretty much every app) as well as update a bunch of keys at once (important for atomicity, even with eventual consistency)
Also, it seems it went from 10ms for the $5 account to 50ms as far as the CPU bandwidth per request. Why 50ms? Why can’t we pay extra for say 300ms? I know that 300ms is a very large chunk of CPU bandwidth but I have no idea how powerful those CPUs are so to me 50ms is a very arbitrary number. Unless you publish the data model behind your decision to limit it to 50ms I cannot say that I understand the reason. It could be a number that is derived based on your (internal) performance SLA for Workers (given N workers share the same hardware and ultimately a finite number of CPU cores/cycles.)
event.waitUntil(): is there a guarantee that it will actually let some already executed async task to continue to run until the Promise is resolved? There must be a limit. What if the Promise is not resolved for 2000 hours? What is the limit before the async task is cancelled? After all, I don’t see how you can even guarantee that a worker can run indefinitely (i.e. 100% uptime) since sooner or later it will fail, but my question is not about that inevitability. My question is about whether or not there is a timeout value that is simply missing in the docs. Btw, I learned about waitUntil from random googling, so I don’t know if it’s still supported, but just in case.