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)
I work at Cloudflare. This limit is a part of our abuse protection system. We are happy to raise it for anyone and everyone with a legitimate need, no need to be an Enterprise account. Please feel free to reach out to workers-developer-help [at] cloudflare.com if you run into trouble.
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.
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.
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...
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.
We have a Recipe for 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
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.
(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.
> 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!
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?
19 comments
[ 3.3 ms ] story [ 55.2 ms ] thread- 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)
(I kicked off the lengthy internal FAQ that covers this exact point...)
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.
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.
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.
> 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/
I answered a lot of these sorts of questions in the original announcement blog post:
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?