
Cloudflare Workers Recipe Exchange - jgrahamc
https://blog.cloudflare.com/cloudflare-workers-recipe-exchange/
======
forcer
Cloudflare Workers are a very good piece of tech. We have been using this in
production for some time. Some gripes we have with this though:

\- There is a limit of about 1k requests per minute per IP - this limit is
possible to change only on Enterprise plan. - this hurt us because we use
Workers as protection layer for our API, and some our API users use more than
1k requests per minute, they get blocked by Cloudflare.

\- Workers Routes are case-sensitive - yes I know URLs on Linux are case
sensitive but on Windows they are not, with this its very difficult/impossible
to use Routes for websites hosted on Windows platform (Azure/IIS)

~~~
kentonv
Workers tech lead here.

On the first point: As others have noted, we're happy to lift the rate limit
for any customer (not just enterprise). If a support person told you
otherwise, I apologize! Please e-mail us and let us know who said that so we
can make sure they have the correct info.

On the second point: You could always map your worker to "*", and then write
JavaScript code that uses a case-insensitive regex to do the real URL
matching. We've been trying to keep the configuration around Workers as light
as possible since most things can be implemented in code in the worker itself.

~~~
forcer
the limit has been lifted! Thanks Cloudflare.

yes you got point about case sensitivity. in our case it would not work though
because we wanted to use Routes to save on API calls to worker due to limits.
Now with no limits we don't need this workaround using Routes.

~~~
kentonv
Sorry you had to go through all that trouble. We need to improve the process
of lifting the rate limits so that people don't think they're stuck with it...

------
tsavola
The title is misleading if one doesn't know that Cloudflare Workers are a
thing. I honestly thought that it was about Cloudflare employees sharing food
recipes with each other.

~~~
adenner
For a moment I also thought it was a bunch of food recipes like
[https://github.com/owen2/NerdyCrockpot](https://github.com/owen2/NerdyCrockpot)

------
yvoschaap
We have a Recipe for [https://teampa.ge](https://teampa.ge) which removes the
need for our customers to embed our javascript snippet! It feels so much more
better then having to ask people to change their website code. See:
[https://m.youtube.com/watch?v=pVFZN8ZQiiQ](https://m.youtube.com/watch?v=pVFZN8ZQiiQ)

------
grx
While I really like the idea of creating more complex policies at the edge,
please remember that Cloudflare Workers are a vendor lock-in. If you proxy
your servers with Cloudflare and use their API for more than simple request
handling, you rely on their good will to stay online and keep the
functionality you outsourced to their Worker API.

~~~
kentonv
(I'm the tech lead / architect of Cloudflare Workers.)

CF Workers is based on the Service Workers API, which is a W3C standard that
has existed in browsers for some time. The only real vendor-specific additions
we've made are flags to turn on/off other Cloudflare features; most people
don't actually use those flags. So, even today, a worker you write for
Cloudflare can potentially be moved to run in the browser with minimal code
changes. (Of course, not all scripts are safe to run in the browser, e.g.
access control checks.)

Unfortunately, many competing edge compute and "serverless" products have
chosen to invent their own, proprietary APIs, rather than use a standard. My
sincere hope is that this will change, and in the future, we'll see a
convergence on Service Workers. It fits this use case very well, and it's
already a standard.

More generally, I think the future is in code that can seamlessly move around,
between your servers, client browsers, "the edge", even other people's
servers, running wherever it's most useful, perhaps without the developer even
needing to think about it. There's far less value in a closed platform with
immobile code. And in any case, we aim to win by building a better (larger,
faster, less-expensive) network, not by trapping people.

~~~
grx
Thank you for the reply!

> _CF Workers is based on the Service Workers API, which is a W3C standard
> that has existed in browsers for some time._

> _Unfortunately, many competing edge compute and "serverless" products have
> chosen to invent their own, proprietary APIs, rather than use a standard. My
> sincere hope is that this will change, and in the future, we'll see a
> convergence on Service Workers. It fits this use case very well, and it's
> already a standard._

That's really nice to hear. After the fallout the Github acquisition produced
the last days one cannot stress enough how important standardized APIs are for
migration operations. I know that vendor lock-ins are profitable business
models, but I feel like the damage it does to flexible architectures and data-
owning produces more costs in the long run.

> _While Cloudflare does use V8, we do not use Node.js_

Was this ever an option? Did you consider using other languages besides
JavaScript? Like Python or Elixir?

> _And in any case, we aim to win by building a better (larger, faster, less-
> expensive) network, not by trapping people._

Even though I agree with you (as written above) I wonder how Cloudflare aims
to do this. To me, it seems like Cloudflare does have way too much websites
behind their services. Given that Cloudflare has a history with policing [DS]
customers, trust is also an essential feature I'd give top priority. I would
therefore argue that decentralization should also be a feature for resilient
networks, though it's difficult to implement in your case.

Btw, does Cloudflare have any serious competitors besides CDN providers?

Thanks again for your reply, very interested in your expertise!

[DS] [https://blog.cloudflare.com/why-we-terminated-daily-
stormer/](https://blog.cloudflare.com/why-we-terminated-daily-stormer/)

~~~
kentonv
> Was this ever an option? Did you consider using other languages besides
> JavaScript? Like Python or Elixir?

I answered a lot of these sorts of questions in the original announcement blog
post:

[https://blog.cloudflare.com/introducing-cloudflare-
workers/](https://blog.cloudflare.com/introducing-cloudflare-workers/)

The short version is, edge compute calls for an architecture that scales to
extremely large numbers of tenants per machine, since every customer wants
their code to run in every location. Giving each tenant a whole process does
not scale. But we also need secure isolation. So using a JavaScript engine --
built for multi-tenant-per-process secure sandboxing, fast start time, and low
overhead -- is pretty much the only reasonable option.

> Cloudflare has a history with policing [DS] customers,

(Disclaimer: My opinions, I don't speak for my employer.)

With respect, I think the history shows the opposite of what you say.
Cloudflare has a history of steadfastly refusing to police content, even in
the face of intense public pressure to do so, including major press articles
essentially calling us Nazi sympathizers. The incident you reference is the
only time Cloudflare has ever terminated a customer for objectionable content,
and it came with a lengthy explanation from the CEO explaining why he thinks
this is dangerous and does not want to do it again. Other cloud infrastructure
companies terminate customers like this all the time and don't say anything
public about it, so it generates no press.

If you don't believe tech company CEOs should be making decisions about what
people can and can't say on the internet, then Cloudflare is your ally, not
your enemy.

> I would therefore argue that decentralization should also be a feature for
> resilient networks, though it's difficult to implement in your case.

There's network decentralization and there's business decentralization.
Cloudflare's whole product is network decentralization, on a technical level.
But I think what you're arguing for here is business decentralization --
avoiding giving too much power to any one business entity. On that note, keep
in mind that Apple, Google, Amazon, Microsoft, and Facebook are each around
100x the size of Cloudflare on most business metrics.

> Btw, does Cloudflare have any serious competitors besides CDN providers?

Not sure I understand this question. CDN is a core part of our product, and of
course all our competitors are also CDN providers. Why exclude them?

