5 ms·

Cloudflare Workers Recipe Exchange

32 points by jgrahamc 8y ago

forcer 8y ago
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)
- jgrahamc 8y ago
  Have you talked to anyone at Cloudflare about these gripes?
  - forcer 8y ago
    yes, reported to customer support but they just said this is how it works and that's it.
    - jgrahamc 8y ago
      Drop me an email (jgc @ cloudflare).
      - forcer 8y ago
        Thanks! I just sent you email
- elithrar 8y ago
  I no longer work at CF, but the team were always OK with raising the limit on-asking: I’d suggest opening a new ticket and asking for a review. (I kicked off the lengthy internal FAQ that covers this exact point...)
- zackbloom 8y ago
  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.
- kentonv 8y ago
  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 8y ago
    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 8y ago
      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 8y ago
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.
- dvdhnt 8y ago
  Lol no way, but I admit "recipe" and "cookbook" don't really work in software.
- maw 8y ago
  I thought the same, and assumed that they'd made it public as a way to showcase positive corporate culture.
- adenner 8y ago
  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 8y ago
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 8y ago
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 8y ago
  (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 8y ago
    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/

32 points by jgrahamc 8y ago

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)

jgrahamc 8y ago
Have you talked to anyone at Cloudflare about these gripes?
- forcer 8y ago
  yes, reported to customer support but they just said this is how it works and that's it.
  - jgrahamc 8y ago
    Drop me an email (jgc @ cloudflare).
    - forcer 8y ago
      Thanks! I just sent you email
elithrar 8y ago
I no longer work at CF, but the team were always OK with raising the limit on-asking: I’d suggest opening a new ticket and asking for a review. (I kicked off the lengthy internal FAQ that covers this exact point...)
zackbloom 8y ago
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.
kentonv 8y ago
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 8y ago
  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 8y ago
    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 8y ago

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.

dvdhnt 8y ago
Lol no way, but I admit "recipe" and "cookbook" don't really work in software.
maw 8y ago
I thought the same, and assumed that they'd made it public as a way to showcase positive corporate culture.
adenner 8y ago
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 8y ago

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 8y ago

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 8y ago
(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 8y ago
  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/