3 ms·
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
by mark242 8y ago
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 8y agoFull 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 8y agoYeah, 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.