4 ms·

Hi! I'm a product manager working on Workers — didn't come across hater-y to me at all. We will actually be rolling out a new version of our docs soon — hopef

Hi! I'm a product manager working on Workers — didn't come across hater-y to me at all. We will actually be rolling out a new version of our docs soon — hopefully make them easier to navigate, and expose deeper information. If there are any specific subjects or corner cases you've run into that you'd like to see better documented — our docs are open source (so issues are welcome!). We definitely want to make it as easy as possible for you to self-service. Observability and debugging is also a heavy area of investment for us (and I think we've made significant progress here since the launch of Workers). As Kenton mentioned below, wrangler tail is a great way to get a lot of information out of the Worker (and its subrequests) — you can basically log anything. We'd also like to make it easier to log to existing logging platforms from a Worker. If there's any missing information you'd like to see, please do sent me a note ^

dkersten 6y ago
Will there ever be a way to put workers behind the cache (eg maybe the worker can set in the response “yes, please cache this”, the way you already can for the origin, except have it then serve that response rather than run the worker)? Or will workers have an API to interact with firewall rules? Mainly I’m thinking that a major use case for using CF is stuff like DDoS protection, but workers have a per request cost and according to [1] CF’s DDoS protection won’t automatically protect against a layer 7 attack. It seems the options are to either use CF’s rate limiting product (which charges per good request 10x the price of a worker request. Maybe that’s worth it, but it sure makes workers look less affordable than at first), or set firewall rules to block the traffic. For that second option, it would be great if it could be done from inside the worker (although I’m not sure yet how the worker would actually go about detecting that a request aught to be blocked. [1] suggested running fail2ban on the origin and using the firewall API to dynamically update rules — I guess I’m windering if there is a simpler way). Rate limiting seems ideal, I’m just not sold on paying 10x when I don’t know if I’ll even ever need it: maybe simply being able to set optional limits for worker requests after which further requests don’t get serviced, rather than getting billed for an attack? Is that possible? I guess I could count requests somehow myself. and disable the worker. At least then I can make a call between whether uptime is worth the cost of rate limiting or if I can just accept some downtime. [1] https://community.cloudflare.com/t/how-to-protect-cloudflare-worker-from-ddos/179017/3 https://community.cloudflare.com/t/how-to-protect-cloudflare... and https://community.cloudflare.com/t/workers-have-a-critical-issue-or-maybe-im-dumb/173491 https://community.cloudflare.com/t/workers-have-a-critical-i...

dkersten 6y ago

Will there ever be a way to put workers behind the cache (eg maybe the worker can set in the response “yes, please cache this”, the way you already can for the origin, except have it then serve that response rather than run the worker)? Or will workers have an API to interact with firewall rules? Mainly I’m thinking that a major use case for using CF is stuff like DDoS protection, but workers have a per request cost and according to [1] CF’s DDoS protection won’t automatically protect against a layer 7 attack. It seems the options are to either use CF’s rate limiting product (which charges per good request 10x the price of a worker request. Maybe that’s worth it, but it sure makes workers look less affordable than at first), or set firewall rules to block the traffic. For that second option, it would be great if it could be done from inside the worker (although I’m not sure yet how the worker would actually go about detecting that a request aught to be blocked. [1] suggested running fail2ban on the origin and using the firewall API to dynamically update rules — I guess I’m windering if there is a simpler way). Rate limiting seems ideal, I’m just not sold on paying 10x when I don’t know if I’ll even ever need it: maybe simply being able to set optional limits for worker requests after which further requests don’t get serviced, rather than getting billed for an attack? Is that possible? I guess I could count requests somehow myself. and disable the worker. At least then I can make a call between whether uptime is worth the cost of rate limiting or if I can just accept some downtime. [1] https://community.cloudflare.com/t/how-to-protect-cloudflare-worker-from-ddos/179017/3 https://community.cloudflare.com/t/how-to-protect-cloudflare... and https://community.cloudflare.com/t/workers-have-a-critical-issue-or-maybe-im-dumb/173491 https://community.cloudflare.com/t/workers-have-a-critical-i...