21–30 of 58 posts
Earlier quoted context omitted.
Feel free to reach out (email in parent post).
I'm on the Cloudflare Workers team and while I can't help you get access any quicker than the usual route through the form, I'd still love to hear about your specific usecase(s) and limitations. Is it okay if I email you?
Earlier quoted context omitted.
[2] Should be fairly easy to debug, as you can see what routes have actually been bound in the Cloudflare dashboard.
Are you referring to the routes set in wrangler.toml? I tried defining the /ip route there, still got 404.
I read your write up, but I’m not entirely clear on one part: how do cloudflare workers handle websocket connections? Are they automatically terminated after the worker spends too much time active? If so, doesn’t handling the WS handshake have a lot more overhead than a fetch call? Maybe I’m misunderstanding something here. One of my biggest issues with serverless is its inability to handle websockets in a sane way,…
With the Workers Bundled plan (https://developers.cloudflare.com/workers/platform/pricing#b...), your WebSocket connection will stay open until your 50ms of CPU time expires. On Unbound (https://blog.cloudflare.com/introducing-workers-unbound/), which does not have a CPU time limit, your WebSocket connection will stay alive as long as it remains active and your Worker doesn't exceed its memory limits. If the connection goes idle, it may be terminated. We're currently considering an idle timeout on the order of 1-10 minutes.
I read your write up, but I’m not entirely clear on one part: how do cloudflare workers handle websocket connections? Are they automatically terminated after the worker spends too much time active? If so, doesn’t handling the WS handshake have a lot more overhead than a fetch call? Maybe I’m misunderstanding something here. One of my biggest issues with serverless is its inability to handle websockets in a sane way,…
Workers handle WebSockets in a pretty straightforward way. The server-side API is literally the same WebSocket JavaScript API as in browsers. sock.addEventListener("message", callback), etc.
But if you aren't using Durable Objects, then WebSockets on Workers aren't particularly useful, because there's no way to contact the specific Worker instance that is handling a particular client's WebSocket session, in order to send a message down.
Durable Objects fixes exactly that. Now you can have worker instances that are named, so you can call back to them.
Here's a complete demo that uses WebSockets to implement chat: https://github.com/cloudflare/workers-chat-demo/blob/main/ch...
> Are they automatically terminated after the worker spends too much time active?
We're still tweaking timeouts and limits, but in general you should be able to keep a WebSocket alive long-term, and reconnect any time it drops (which any WebSocket application has to do anyway, the internet being unreliable).
> If so, doesn’t handling the WS handshake have a lot more overhead than a fetch call?
Not sure what you mean here. A WS handshake in itself isn't terribly expensive. I suppose a typical application will have to establish some state after the socket opens, and that could be expensive, but it depends on the app.
Are there any large companies that use cloudflare workers in production?
Yes: https://www.cloudflare.com/case-studies/?usecase=Deploy+cust... From our Q3 earnings call: "Turning to Cloudflare Workers, it's incredibly exciting to see how the platform is taking off. In Q3, more than 27,000 developers wrote and deployed their first Cloudflare Workers. That's up from 15,000 a year ago. History proves with new computing platforms, the more developers they have, the more quickly they improved a…
> Given Cloudflare's network spans more than 200 cities in more than 100 countries worldwide...
I think, only the enterprise customers can truly claim benefit of all 200 PoPs. Free/Pro/Business(?) plans aren't necessarily routed to all 200. If that's not the case, then it doesn't match our interaction with Cloudflare's support.
---
That said, I absolutely love Workers. It is quite easily the best value for money of any edge computing platform. This blog post drives those arguments home: https://medium.com/@zackbloom/serverless-pricing-and-costs-a...
[0] On the flip side, because of CNAME Flattening, it is hard to block privacy eroding solutions such as these: https://www.cloudflare.com/apps/google-analytics
Earlier quoted context omitted.
Feel free to reach out (email in parent post).
I'm on the Cloudflare Workers team and while I can't help you get access any quicker than the usual route through the form, I'd still love to hear about your specific usecase(s) and limitations. Is it okay if I email you?
Earlier quoted context omitted.
I'm on the Cloudflare Workers team and while I can't help you get access any quicker than the usual route through the form, I'd still love to hear about your specific usecase(s) and limitations. Is it okay if I email you?
Does there happen to be a local simulator one could use to build out an app?
Also perhaps try playing around in https://cloudflareworkers.com/
I don't believe Workers _Durable Objects_ specifically is available to play around with outside of the beta, however - apologies if that's what you actually wanted to play with. We're working hard on building and perfecting it into a product that everyone will be able to use soon, so keep an eye on this space.
Is there a specific usecase you have in mind? I'd love to hear about it!
Earlier quoted context omitted.
Does there happen to be a local simulator one could use to build out an app?
I don't know about a full-blown local sim, but perhaps https://blog.cloudflare.com/trailblazing-a-development-envir... is close enough to what you have in mind? Also perhaps try playing around in https://cloudflareworkers.com/ I don't believe Workers _Durable Objects_ specifically is available to play around with outside of the beta, however - apologies if that's what you actually wanted to play with. We're working h…