Number of pops is of course critical to a CDN both in providing more availability in a more diverse set of locations, but also in terms of providing a larger backbone and more capacity to protect again attacks and spikes.
Also CF uses anycast geolocation, which is the easy fast way to market, but not nearly as reliable or controllable. You just start buying some colo and let the internet do its thing, and be at the mercy of their peers. Most bigger CDNs and content providers don’t do this for that reason.
Do you work for one of those other CDN providers by chance? It certainly takes a fair bit of work to get an anycast network working, but it's not nearly the controversial move it was eight years ago.
If you ever decide to put together remote teams be sure to announce it. It looks like you are doing interesting work, but I'm not interested in moving to any of those cities (and I'm probably not alone).
Workers are amazing! Because they have a trivial startup time and cost compared to lambdas, you can do crazy things like proxies with deep rewriting of content, etc. Have a SaaS that you use on a subdomain of your site, and wish you could inject code or a tag manager for analytics? Route the whole subdomain through Cloudflare and rewrite body tags on HTML, or intercept other requests in transit, you can deploy this in minutes. Build custom image proxies and change cache times dynamically. Build your own round robin systems. Possibilities are endless.
Are you comparing them to basic AWS lambda or lambda@edge? It seems like CF workers are similar to edge functions where you can modify request/response.
We have such a blacklist in our actual implementation but it didn't find its way into this reservation page. We won't actually be letting people use those names.
For people who're only looking to reserve one subdomain - this might cause an issue. They might think they got `website.workers.dev` when they would have been equally happy with `awesomewebsite.workers.dev`.
Good advice. Back when I ran a small ISP a customer asked to register gov.com and we got it! Soon after I wondered why my DNS server was bogging down. There were hundreds of requests per second to whitehouse.gov.com. We got the NSF to block that from ever happening again.
This sounds cool and makes me want to fiddle with it, but I can’t think of any use-cases. What kinds of things would you use this for? It can’t connect to a db, except over some REST-like interface, presumably, as it’s just a vanilla v8 worker. Right? And using v8 for compute alone seems a bit of a bad fit. So I’m genuinely curious what the use-case is.
It breaks down into a few categories, organized by how futuristic they are:
CDN extensions: People who have always wanted to be able to cache POST requests, or aggregate responses but haven't been able to do it with the limitations imposed by traditional CDNs. Workers moves what was a configuration language into a full Turing-complete programming environment which can make subrequests, interact with the Cache API directly, etc.
Pushing out to the edge: There is a long list of services which are best done close to users but don't require a huge amount of state. For example, you might want to validate access tokens before requests hit your infrastructure, or do many of the other things commonly done in an API gateway. You also might want to move performance critical components of your API which don't require much state closer to users, things like aggregating and caching GraphQL or prerendering your React app. We have a Workers KV product which gives you just enough state to handle many of these cases in beta now.
Serverless apps: This is what workers.dev is all about. The idea that if you _can_ deploy code to a network almost as large as the Internet itself is it possible that is a better model than deploying to a single region or availability zone? Without cold-starts you get instant scaling to almost any volume of traffic which is a big advantage, to the point where this type of serverless seems faster and cheaper even if you ignore the network. As you mention it will require better distributed storage tools, but we're optimistic those will become available in the near future.
I wish HackerNews had a way to save comments so I could flag this and come back to it in a few days when answers are more fleshed out so I can learn. Any ideas?
You can upvote or favorite. I use favorites a whole lot less than upvotes, which makes them more searchable. So although favorites are public (upvotes are not), I sometimes favorite a thing I would like to revisit.
Workers are pretty neat. I've been using them as a mechanism for serving private Wasabi/Backblaze B2 buckets publicly, ideally so I can host project assets with more predictable costs. This is a very practical and useful case for workers, IMO -- it stops unintended outbound egress from origins, and gives better routing -- both B2 and Wasabi peer with CloudFlare to waive any applicable egress fees. So I basically pay a flat $5/month + B2/Wasabi storage costs (approx $5/mo/TB) and zero egress, more or less.
Overall it's worked pretty well; it's also useful for doing things like setting up fully 'virtual' domains when using an object store, e.g. set a CNAME for 'foo.bar.com' to 'example.com' and then write a worker that just intercepts every `foo.bar.com` request and routes appropriately. This has worked surprisingly nicely. For example, I host one of my recent projects under https://riscv.ls0f.pw/ but this subdomain doesn't really "exist" beyond being a CNAME for example.com; it's just routed directly to a B2 bucket subpath, in the background.
At the moment I'm working on a mechanism of automating my worker deployments using GitHub Actions and seeing how writing them in OCaml/BuckleScript goes (a much more tedious process), but overall it's pretty neat and useful for writing quick routing glue and whatnot.
If anyone from the CloudFlare team is reading this, probably the most important feature I'm looking forward to is resource bindings for cryptographic keys, to be used with the WebCrypto API, so plaintext keys are not visible directly in the worker source code. Is there any ETA on when this might be GA? In my case it's the most important feature currently missing, and it's really crucial for a lot of practical use cases.
EDIT: also, another really useful feature (for me), but admittedly maybe niche, would be "atomic-compare-and-update worker script", i.e. I want to submit a JavaScript file to the API and only update the worker iff the new source code is not equal to the existing source code. The reasoning here is that I currently download the worker script and 'diff' it against the new one as a test, and only upload if they're actually different. I could simply re-upload every time but I'm not sure if this invalidates any 'hot' worker instances that are already running. Perhaps the upload API can simply be extended with new return codes to indicate this...
> the most important feature I'm looking forward to is resource bindings for cryptographic keys,
Given the specificity of your request, I'm guessing you're aware that this feature already unofficially exists, with unlisted-but-googlable documentation. :) As long as you always deploy workers via the API -- never the UI -- then it's safe to use the feature now. If you accidentally edit your script in the UI, the secret bindings might be dropped, since the UI doesn't understand them yet.
> I could simply re-upload every time but I'm not sure if this invalidates any 'hot' worker instances that are already running.
Good news: If you upload exactly the same script, your live workers won't be restarted. This is a side effect of the fact that we use a content-addressable store for scripts. (Similarly, if you go to cloudflareworkers.com and enter the exact same script twice, you'll notice the resulting URL is the same.)
Are you actually observing non-negligible cold start times, though? Usually the cold start time is so low that you can't really tell when it happens.
Yes, I did find the google-able documentation, but I wasn't sure if the API worked or not, or it was just a temporary vision of the future, etc -- I guess I simply didn't try. :) Perhaps once my GH Actions Workflow is figured out I can migrate to this, and open source it (though it's tied up with my OCaml code at the moment...)
> Are you actually observing non-negligible cold start times, though? Usually the cold start time is so low that you can't really tell when it happens.
Honestly, no, it was just something I realized when writing my workflows -- that I don't know from the API how to tell if a worker is "up to date or not" other than downloading and comparing. All of my tests have been exceedingly simple (for now) so it was more just a cautious pre-optimization to make sure I didn't tank something later on a script unrelated to the one I was working on (my workflows upload all scripts across domains during CI, iff they changed).
Oh! Here's one more feature request, though: atomic route/filter updates for scripts would be really nice. Right now I kind of iterate through them and match/delete/update them one by one, because overlapping routes cause errors. This means actually doing an insert or update or create is a bit complicated -- you need to actually grab the list of existing routes up front and match IDs with the corresponding route paths, before you can determine what to do (if it already exists, update, if it no longer exists, delete, otherwise, insert, etc)
But it would be a huge simplification if I could say "Atomically replace the current routes with this set of routes all at once". I'm not sure how easy this is on your end, though. Now that I think of it, I guess I can just immediately wipe and insert a whole new set, though, since it's not like the current solution is atomic anyway!
Yeah, we should have had the routing table be one unit all along. We plan to change it to work that way soon and deprecate the one-route-at-a-time API.
Unfortunately there is no way to propagate an environment variable thru a Worker. The closest equivalent is in fact this "resource binding" mechanism I mention -- but it's a bit different -- where as an environment variable binds `FOO=BAR` in an associative dictionary (where you lookup 'FOO'), setting a resource `FOO=BAR` with Workers actually injects a value named `FOO` into your script, which contains a string. So it's just an ordinary JavaScript variable.
So it's not injecting environment variables, it's inserting lexical bindings into the script and then running it. But the end results are more or less the same.
At the moment, no, but in theory if I had access to Workers KV (I do not), I could probably build something like that relatively easily. But, I haven't needed it at all -- maybe later when I plan on uploading some bigger public datasets in the ~100GB range. As I said, it's mostly just an insurance method to shield the buckets from non-CloudFlare access, making sure screw ups/meanies, etc don't get to hit my wallet with egress bandwidth charges, which would make me sad. Peering, not the caching/CDN layer, is the real benefit.
Also, the worker includes a mini-router I wrote, making it relatively easy to redirect subdomains or subpaths of a domain to different buckets or subdirectories of a bucket, etc. It's really only like 30 lines of code, tops, but it makes it relatively easy to route multiple projects in a single bucket onto shorter, more stable names.
So it's not really anything special at all. It's just convenient and now I don't have to run anything else to serve things "safely" from my object storage. Also, if you use Wasabi, you get an S3 API endpoint, so you don't have to run proxies or write adapter code for your upload-path, which is a huge boon. I actually saved money on my upload-path by being able to get rid of my minio proxy and supporting code by using Workers in this way.
Workers are awesome. They are so innovative in a truly transformative way. It will be exciting when/if the cpu time gets extended so this can be used for server side rendering of user interfaces, such as with react.
I think my favorite use case at the moment is to use them as a fault tolerant highly available proxy solution. So you could have mydomain.com/blog be served by a microservice that is separate from your primary monolithic app.
Basically it lets you run JS code on every request, much like Lambda. Differences:
1. It's JS but not Node.JS - You write against the service worker API and they run it in a vanilla V8. You'll want to webpack your stuff together or something like that.
2. Because it's V8 and not Node, they can run many customers in the same process (as safely as multiple sites can coexist in Chrome tabs), and therefore it's cheaper than Lambda.
3. It runs on the cloudflare edge nodes, i.e. close to the user, instead of some AWS region on the other side of the world, so latency can be lower. Can be, because for many (most?) use cases you'll still need to call some API somewhere else, eating up most latency wins you might make. They do also have a distributed KV store that might help you address this, however.
To add on to that last point, you don't need to pick in advance which region or regions your code will run in. You push your code once, and it will run in whichever edge locations receive requests, potentially all 165+ locations if you have users sufficiently spread around the world.
> as safely as multiple sites can coexist in Chrome tabs
Chrome tabs usually run in different processes. It sounds like Cloudflare is using JS isolates within the same process to run many customers.
This sounds scary to me. For security, the Chrome team assumes that any code running in the same process has access to the whole address space of that process due to all of the recent speculative execution issues (Spectre/Meltdown).
I've seen comments on HN say that this isn't a problem for cloudflare because they do special things with all of JS timing APIs and a few others to mitigate.
Will be interesting if they are able to make this secure. Millisecond cold startup times will be amazing for development.
Well, maybe I'm wrong :-) my relationship with CloudFlare ends at me being a customer, there is a significant chance that my impression of how Workers (or its security setup) works is wrong. If you want to be sure, ask CF.
In the conclusion of a recent Spectre paper published by a number of Google security researchers they write:
"The community has assumed for decades that programming language security enforced with static and dynamic checks could guarantee confidentiality between computations in the same address space. Our work has discovered there are numerous vulnerabilities in today’s languages that when run on today’s CPUs allow construction of the universal read gadget, which completely destroys language-enforced confidentiality"
CloudFlare believes this doesn't apply to them and that they have created defences which allow them to run multiple customers' code in the same address space without leaking memory. I think the burden of proof is on CloudFlare, and I'm yet to see them actually publish any information about this.
That’s not quite true. They do have different limits than regular Lambda functions, but you can certainly make requests to arbitrary hosts. The documentation puts it like this:
> Functions triggered by origin request and response events as well as functions triggered by viewer request and response events can make network calls to resources on the internet, and to AWS services such as Amazon S3 buckets, DynamoDB tables, or Amazon EC2 instances.
Looks like a cloud based JavaScript V8 runtime (NodeJs-like?). $5 minimum/month ($0.50/million requests after the first 10 million). Here's an article[0].
Seems like an interesting service for someone, to do something...
One way to think about it is: why not do everything on top of a network like Workers? Does it actually make sense to deploy services to a single location when they can be trivially started up near every user?
Noticed this when double clicking a word to highlight it - at first I thought it was one of those badly designed sites where you literally can't select anything and then it selects everything at once. But no, it's a fancy night mode, very good job Cloudflare! :)
> As a part of Google’s TLD launch program, we were lucky enough to obtain workers.dev
This is not 'luck'. You pay the $11,500 fee and with a domain like this you would most likely get it. Many domains are available at the highest fee (previous post). The only way you would need 'luck' is if more than one person wanted this and beat you out. With this particular domain this is unlikely.
For example as of right now (way past launch) all of the following are still open at the highest rate:
digital.dev
bitcoins.dev (bitcoin.dev is taken already)
php.dev
sql.dev
Honestly knowing a bit about this they could have waited and gone in at the lower tiers.
Also the singular is open worker.dev and as a best practice they probably should have bought that (edit: also).
As someone new to serverless, are there ways for Cloudflare Workers to authenticate against a specific web app/SPA in cases where the app doesn't require user login/authentication to work? Or is that effectively impossible in that case?
What sort of authentication? Are you trying to ensure that only your webapp hits your backend (which in this case is implemented in Workers)? That's generally impossible on the web, as all the code in the browser used to hit it is accessible to visitors.
Sort of shocking Amazon or Microsoft have not yet acquired them given where the markets seem to be going