[mark242]

The more work you can offload to an edge node, the better-- this is a pretty safe general rule to make.

Think of all of the random conditionals that your http routes have; "is the client posting a correct data structure" or "is this a valid OAuth token" or "am I requesting something that I already have cached" or rate limiting or the list goes on and on.

All of that kind of stateless route level logic that may not need to hit a data store is a perfect candidate for an edge worker, because once you have that deployed, you can concentrate more on business logic within your main application.

For example: "I have a valid OAuth token, I have established my identity, now issue an S3 pre-sign request and forward the resulting URL to the browser to download a protected file". Doing that within a worker will absolutely speed up your user experience by a couple hundred milliseconds at least.

[rita3ko]

Full disclosure - I work on Workers at Cloudflare, so obviously biased :)

There are a lot of performance advantages along every step of the way, as you mention. I think you can look at this from many different lenses beyond performance.

A big advantage was how fast and easy this was to get up and running. Simplicity is key here - it's a simple API written in JavaScript (no config, VPS, etc necessary).

The other really important thing is scalability - when workers.dev went live, we didn't have to worry about being able to handle the spiky workload (preregistration sites end up failing quite frequently). This scales infinitely.

[mark242]

Yeah, agree-- the moment that you all get KV to mature to a more Dynamo-like experience with queries and secondary indexes, that opens up a whole ton of possibilities in terms of easily rolling out entire applications that can scale from zero to whatever size.