
Code Everywhere: Why We Built Cloudflare Workers - somecoder
https://blog.cloudflare.com/code-everywhere-cloudflare-workers/
======
dx034
> the most peered network on the planet

That's a bold claim. I'd expect Akamai, Google and Amazon to be peered at more
locations, maybe even more. Or have they become that big?

~~~
jgrahamc
Yes. We are that big.

[https://bgp.he.net/report/exchanges#_participants](https://bgp.he.net/report/exchanges#_participants)

~~~
NicoJuicy
Who is hurricane electric?

~~~
somecoder
[https://en.wikipedia.org/wiki/Hurricane_Electric](https://en.wikipedia.org/wiki/Hurricane_Electric)

------
cavisne
Very similar to lambda@edge

Trade offs I see

* Cloudflare is probably slightly closer to customers, but cloudfront is still very close

* lambda@edge should be cheaper with amazons scale and ecosystem

* cloudfront itself is very expensive compared to Cloudflare, almost every project can integrate Cloudflare and use this, where small projects don’t really make sense for cloudfront

~~~
kentonv
> lambda@edge should be cheaper with amazons scale and ecosystem

I suspect price will have more to do with the tech's underlying ability to
scale to lots of (separately-sandboxed) customers at lots of edge locations.
Our tech is pretty different from Amazon's so it will be interesting to see
how that shakes out.

------
Matheus28
It would be amazing if those workers supported WebSockets. Running game
servers in them would be tempting, as long as they don't charge exorbitant
prices for bandwidth.

~~~
kentonv
WebSocket support is planned (not sure if it will be in v1).

The issue with game servers is that you probably need to make sure all the
players in the same game instance hit the same worker. There won't be any way
to do that with workers in v1. But, this is definitely something we've thought
about, and as a big gamer myself I would like to see it happen someday. I have
some particular ideas for a different kind of worker (not a Service Worker)
that serves this use case. But it's probably a year out.

------
kennethh
This is pretty interesting, especially if one get some kind og local storage
where one can cache the data from the users and also keep some extra data one
need to handle the requests. One can also imagine some kind of MQ solution
that distribute to the edges and then updates the clients (for games and such
scenarios)

~~~
jgrahamc
Yes. We are exploring adding data storage at the edge. We would love people’s
feedback in the product and what features we need to add.

~~~
Navarr
It sounds like you're slowly working towards becoming some sort of insane
hosting company

~~~
jgrahamc
I don’t see us going into hosting. I do see us doing everything that makes
sense when you are a few ms from everyone on the planet.

~~~
random023987
> Run JavaScript Service Workers at the Edge

> We are exploring adding data storage at the edge.

> I don’t see us going into hosting.

You must have your eyes closed then, because that's clearly pushing the camel
nose into the Amazon lambda tent.

------
remline
How does this deal with proxy loops?

As an example, I would assume worker is making requests with the internal view
of the site, but can not have an internal view of other sites or security
problems would ensue.. So what happens when two of my sites have service
workers fetching something from each other on each request?

~~~
kentonv
As you guessed, when your worker makes a subrequest to your own zone, it goes
directly to your origin server, but when you subrequest to some other domain,
it goes in "the front door", and that other domain's scripts apply.

If a request bounces back such that the same worker script would need to run
twice as a result of a single original request, then it fails with an error.
There's nothing else we can do here: we can't let the request loop, but we
also can't let it skip your script after it's bounced through a third-party
script.

~~~
predakanga
To clarify, yesterday you mentioned that subrequests go through the regular
caching subsystem.

Does this hold true even for subrequests to your own zone, where you say here
that they go directly to the origin server?

~~~
kentonv
Yes. I meant that those requests don't loop back into the Worker again -- I
didn't mean that they skip cache.

------
Navarr
Summary: Service Workers on the Edge Server.

Very interesting, especially since it allows for a Cloudflare ESI system.

Wonder if many will take advantage of it

~~~
_asummers
What is ESI in this context? Edge Server Infrastructure?

~~~
Navarr
Edge Side Includes. Imagine putting some sort of template syntax in a file,
that file is cached, and when it's called from cache it grabs a file from the
remote server based on the template syntax.

~~~
predakanga
Notably, implementing ESI directly at Cloudflare's edge enables them to cache
page fragments, rather than fully constructed pages.

That could do wonders both for the size of caches and for cache hit-rates

