Writing an API at the Edge with Workers and Cloud Firestore | Hacker News Reader

Writing an API at the Edge with Workers and Cloud Firestore

blog.cloudflare.com

34 pointsitcmcgrath9 comments

It seems to me that the benefit of Workers is that they run geographically near the user. If the Worker is calling a database that may or not be close to your user, what is the point? You are going to pay the latency cost either from the user to the Worker or the Worker to the DB.

I realize that there are some advantages. The network between the Worker and a Google datacenter is probably much faster than the network from the user to the Worker. Also, Firestore in particular can be geographically replicated so that the database is closer to your user. But I'm not convinced that these benefits outweigh a more traditional (and more flexible) architecture.

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.

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.

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.

One example would be where you have conditional logic that requires a database call. Without workers, everything would go back to the backend system, perhaps across the ocean. With workers in front you could shortcircuit that for all calls that don't require the DB call. You could also handle routing logic at that layer, allowing it to pick closer DB instances, etc.

[Disclaimer: Product Manager on Cloud Firestore who thought this was an interesting use-case]

I have to agree with you. I would really really love to use workers, but I'm having a hard time finding a use case. Sure it's closer to the user, but we're only saving 100ms? I get that certain applications benefit from this, but like you said if I still have to make calls to other API's that aren't at the edge then what does it matter?

This is true today but I feel more and more infra will start moving towards the edge. Cloudflare already has a very basic distributed key-value DB in beta.

yeah i dont see the point of this except for some trivial endpoints

I can't wait to try out Workers. I've always found "serverless" interesting in concept but the cold starts and vague pricing keep me away. It's pretty cool that Workers actually makes latency better rather than neutral/worse.

Reply on news.ycombinator.com