Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Durable Objects in Production

linc.sh

Post reply on HN
Print view View original

31–40 of 58 posts

Re: Durable Objects in Production

#31

Post by jkarneges »

AnthOlei wrote: post #18

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,…

My understanding is a Durable Object is similar to a long running JS app in a respawnable/relocatable container (imagine a Kubernetes deployment of 1 pod). There is always exactly one instance, somewhere. And because the instance is long running, WebSockets become more practical.

Note that because Durable Objects are long running computations, they are stateful and deployments are disruptive (clients disconnected). So even though you could potentially put them in the "serverless" category, the deployment experience isn't quite the same as short-lived serverless functions / lambdas.

The real novelty of Durable Objects appears to be their intended usage of fine granularity (and the underlying tech that enables this). For example, if you were building a chat room service, you could have 1 Durable Object per room. Of course, you could conceivably build a chat room service running 1 Node.js process per chat room on traditional VMs or containers, but that probably wouldn't scale well.

Re: Durable Objects in Production

#32

Post by Jamie9912 »

eli wrote: post #7
gauravphoenix wrote: post #5

it would be so great to see support for other languages like Java, Python, Go etc...

It does support other language, kinda. https://github.com/cloudflare/python-worker-hello-world It just compiles to javascript

The "Python" support really does feel like too much of a hack to do anything real with

Re: Durable Objects in Production

#33

Post by haneefmubarak »

fiddlerwoaroof wrote: post #30
haneefmubarak wrote: post #29

Earlier quoted context omitted.

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…

I had a little e-vite app I was trying to build with the KV store, but the consistency model wasn’t a great fit. I’ve sent an email in for the Durable Objects beta, but it’d be nice to have access to a simulator of some sort just so I can see if it’s a better fit.

Let's talk consistency models and more! Is there a good email I could reach you at - or alternatively, could you send me an email with your requirements (haneef@)?

Re: Durable Objects in Production

#34

Post by kentonv »

jkarneges wrote: post #31
AnthOlei wrote: post #18

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,…

My understanding is a Durable Object is similar to a long running JS app in a respawnable/relocatable container (imagine a Kubernetes deployment of 1 pod). There is always exactly one instance, somewhere. And because the instance is long running, WebSockets become more practical. Note that because Durable Objects are long running computations, they are stateful and deployments are disruptive (clients disconnected). S…

Thanks, you explained it much better than I could.

Re: Durable Objects in Production

#35

Post by dwwoelfel »

greg-m wrote: post #24
AnthOlei wrote: post #18

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,…

Hey, I'm the PM at Cloudflare for WebSockets on Workers. Support is still in beta, so we're still working through the timeout details here. 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…

I'm having some trouble understanding the pricing of Workers Unbound. How much would it cost to keep one websocket connection open for a month?

Re: Durable Objects in Production

#36

Post by realmod »

What a great write up! Looks very promising. Right now, I'm wondering how everything will be priced, especially, the compute-time. Because if the price is low, you would be able to replace a lot of complicated servers with easier and more scalable workers.

According to [0], they will - obviously - charge for both compute-time and storage operations, and with the price of storage operations expected to be around Workers KV. Assuming that compute-time is charged at minimum at-or-higher than Workers Unbound, using workers for chat-rooms and other WebSocket stuff would be unfeasible. Workers Unbound costs $12.50 per MM-GB-sec - given that the server is 128 MB (the current fixed memory size) - the price per-worker-second would be at least $0.0000016 per connected-worker. It could get expensive fast.

[0] https://news.ycombinator.com/item?id=24616775

Re: Durable Objects in Production

#37

Post by kentonv »

realmod wrote: post #36

What a great write up! Looks very promising. Right now, I'm wondering how everything will be priced, especially, the compute-time. Because if the price is low, you would be able to replace a lot of complicated servers with easier and more scalable workers. According to [0], they will - obviously - charge for both compute-time and storage operations, and with the price of storage operations expected to be around Worke…

We're definitely going to figure out some sort of pricing for WebSockets that doesn't charge full price for idle time, but we haven't nailed it down yet.

Re: Durable Objects in Production

#38

Post by a_imho »

realmod wrote: post #36

What a great write up! Looks very promising. Right now, I'm wondering how everything will be priced, especially, the compute-time. Because if the price is low, you would be able to replace a lot of complicated servers with easier and more scalable workers. According to [0], they will - obviously - charge for both compute-time and storage operations, and with the price of storage operations expected to be around Worke…

It could get expensive fast.

Also with paid Workers and no stop loss what happens if someone decide to ddos your app? I searched for this and come away with no clear answers.

Also wondering where will Worker KV fit in? From what I gather Durable Objects are strictly superior if pricing will be comparable.

Re: Durable Objects in Production

#39

Post by kentonv »

dwwoelfel wrote: post #35
greg-m wrote: post #24

Earlier quoted context omitted.

Hey, I'm the PM at Cloudflare for WebSockets on Workers. Support is still in beta, so we're still working through the timeout details here. 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…

I'm having some trouble understanding the pricing of Workers Unbound. How much would it cost to keep one websocket connection open for a month?

We haven't published pricing for WebSockets yet. Obviously directly applying the Workers Unbound duration-based pricing wouldn't work very well; we'll figure out something better.

Re: Durable Objects in Production

#40

Post by brabel »

a_imho wrote: post #38
realmod wrote: post #36

What a great write up! Looks very promising. Right now, I'm wondering how everything will be priced, especially, the compute-time. Because if the price is low, you would be able to replace a lot of complicated servers with easier and more scalable workers. According to [0], they will - obviously - charge for both compute-time and storage operations, and with the price of storage operations expected to be around Worke…

It could get expensive fast. Also with paid Workers and no stop loss what happens if someone decide to ddos your app? I searched for this and come away with no clear answers. Also wondering where will Worker KV fit in? From what I gather Durable Objects are strictly superior if pricing will be comparable.

From what I understand after going through the docs, KV is currently the only way to store data in Workers, and Durable Objects are going to be the new alternative.

KV is eventually consistent, appropriate for low-value data that is read a lot , written infrequently... Durable Objects will provide consistency, at the cost of not having the very low latency of KV because it has to run in a single location instead of on the edges. So there seems to be room for both solutions.

About DDOS, I believe Cloudfare is a leader in ddos-protection, so I would hope they include protection in all their Workers (pls someone correct me if I'm wrong).

Post reply on HN