What compelling use cases have you seen for this technology?
I would put them into three broader categories: 1. Additional functionality built on Workers: the interesting thing with Workers is that it can be a standalone function, or it can act as a proxy. That means that customers can easily add new functionality on top of existing APIs for example, without having to migrate the whole thing to Workers at once. One interesting example of that was an e-customer used Workers to add a barcode generator funcionality for one of their customers.
2. Applications built on cache: the way CDN usually works is that you build an application, and put a cache on top of it. That comes with all sorts of limitations around what you can and cannot cache. I think with a built in cache, we're going to start seeing more cases where the cache is written to from the beginning. This enables customers to do things like cache content for logged in, or paid users by doing the auth on the edge next to the cache, rather than at the origin. Or easily update only certain chunks of what's in the cache, and thus do all sorts of customization at the edge, without necessitating added latency.
3. Standalone serverless apps: there are a few very interesting examples here, one of which we'll be able to talk more openly about in a few days. I think SamKnows is a good one: they were able to build a download speedtest directly from Workers [1]. Another good one was building the reservations website for Workers.dev - we were able to get that service spun up very quickly, and have it scale infinitely to handle the influx of traffic [2]. Similarly, Cloudflare Access is built entirely on Workers (we are pretty excited about dogfooding!).
A couple random cool ones: I've seen some experimentation with ML on the edge (very much POC, and very early, but everything starts somewhere). And DNA sequencing analysis, which really blew me away [4]
[1] https://blog.cloudflare.com/the-samknows-cloudflare-platform... [2] https://blog.cloudflare.com/api-at-the-edge-workers-and-fire... [3] https://blog.cloudflare.com/building-serverless-apps-with-wo... [4] https://twitter.com/RobAboukhalil/status/1121095204281430016
I don't get how this would work. For someone logging in you still have to talk to a central database holding the authentication information. Really anything with a database has a similar problem if you want to enforce consistency.
To use the subdomain example, say you want to prevent two people from reserving the same name. That means the reservation from someone in Sydney has to propogate to the worker in NYC before you can confirm that it has succeeded. Otherwise, simultaneous reservations will result in two successful reservation. So you've lost the benefit of edge workers.
There are many benefits to running logic at the edge, even in situations like that. Scale is a big one to consider: resiliency and single point of failure are very common problems for any floodgate reservation systems. We didn't have to worry about that here.
In general, the more work you can offload to the edge, the better. There's so much logic that goes into handling a reuqest - we see many customers with conditional HTTP routing, validation, rate limiting, etc -- all requiring round trips to the origin. Now they can be done close to the user.