
Writing an API at the Edge with Workers and Cloud Firestore - itcmcgrath
https://blog.cloudflare.com/api-at-the-edge-workers-and-firestore/
======
dgllghr
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.

~~~
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.

------
sosodev
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.

