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

Workers Durable Objects Beta: A New Approach to Stateful Serverless

blog.cloudflare.com

Post reply on HN
Print view View original

71–80 of 98 posts

Re: Workers Durable Objects Beta: A New Approach to Stateful Serverless

#71

Post by treis »

kentonv wrote: post #65
treis wrote: post #55

Earlier quoted context omitted.

>Automatically moving objects to be near the computation that needs it, is a long-standing dream. It's awesome to see that Cloudflare is giving it a try! I'm not sure I see many real world applications for this. It seems to sit in the unhappy middle ground between local device storage and central storage. Local storage is the best performance because you eliminate network issues but then you have to deal with sync/co…

> The performance benefits for the cart, social feed, and chat are irrelevant. Nobody cares if it takes 50 ms longer for any of those things. I think this is missing a few points: 1. Yeah they do. If your shopping cart responds 50ms faster when someone clicks "add to cart", you will see a measurable benefit in revenue. 2. It's actually a lot more than 50ms. A chat app built on a traditional database -- in which a mes…

(1) If 50 ms is that important then the cart should be stored locally and synced in the background. That's my broader point. Performance sensitive things should use local storage. Things that are not should use the convenience of a central server.

(2) Nobody builds chat apps that way. The apples to apples comparison would be something using websockets and Redis. The only savings I see there are the time saved by the server being physically closer.

Re: Workers Durable Objects Beta: A New Approach to Stateful Serverless

#72

Post by kentonv »

treis wrote: post #71
kentonv wrote: post #65

Earlier quoted context omitted.

> The performance benefits for the cart, social feed, and chat are irrelevant. Nobody cares if it takes 50 ms longer for any of those things. I think this is missing a few points: 1. Yeah they do. If your shopping cart responds 50ms faster when someone clicks "add to cart", you will see a measurable benefit in revenue. 2. It's actually a lot more than 50ms. A chat app built on a traditional database -- in which a mes…

(1) If 50 ms is that important then the cart should be stored locally and synced in the background. That's my broader point. Performance sensitive things should use local storage. Things that are not should use the convenience of a central server. (2) Nobody builds chat apps that way. The apples to apples comparison would be something using websockets and Redis. The only savings I see there are the time saved by the…

> Nobody builds chat apps that way.

Of course they don't.

> The apples to apples comparison would be something using websockets and Redis.

Which would be way more complicated to write, deploy, and maintain, and scale than this little 200-line Durable Objects chat demo...

The real point here isn't performance, it's simplicity. But also not having to trade away performance to get simplicity is nice.

Re: Workers Durable Objects Beta: A New Approach to Stateful Serverless

#73

Post by nl »

treis wrote: post #71
kentonv wrote: post #65

Earlier quoted context omitted.

> The performance benefits for the cart, social feed, and chat are irrelevant. Nobody cares if it takes 50 ms longer for any of those things. I think this is missing a few points: 1. Yeah they do. If your shopping cart responds 50ms faster when someone clicks "add to cart", you will see a measurable benefit in revenue. 2. It's actually a lot more than 50ms. A chat app built on a traditional database -- in which a mes…

(1) If 50 ms is that important then the cart should be stored locally and synced in the background. That's my broader point. Performance sensitive things should use local storage. Things that are not should use the convenience of a central server. (2) Nobody builds chat apps that way. The apples to apples comparison would be something using websockets and Redis. The only savings I see there are the time saved by the…

> The only savings I see there are the time saved by the server being physically closer.

Here in Australia, with ping times to US West Coast (where lots of companies host by default) of 170ms this is a real issue.

Re: Workers Durable Objects Beta: A New Approach to Stateful Serverless

#75

Post by kentonv »

proppy wrote: post #74

what's the maximum qps that a single durable object can handle?

An object is limited to one thread. How many qps that is depends entirely on what your app does, since the app can run arbitrary code in the request handler...

Re: Workers Durable Objects Beta: A New Approach to Stateful Serverless

#77

Post by athriren »

kentonv wrote: post #40
pier25 wrote: post #29

If I'm getting this right, it's essentially immediately consistent distributed state for workers. They could have called it simply "Workers State" :) Now in all seriousness, this is super impressive. Congrats to the CF team!

Heh, that is actually a name we considered, and as a name on its own, I like it a lot. But we also needed a name for the individual instances. We also found that the people who "got" the product were the ones who thought of it in terms of object-oriented programming (an object is an instance of a class). So we ended up gravitated towards "objects". But I dunno, naming is hard. "Workers State" may in fact have been a…

workers state is more memorable, mainly because of the double entendre.

Re: Workers Durable Objects Beta: A New Approach to Stateful Serverless

#79

Post by kovek »

This is awesome, and I'm so excited to read through the chat.mjs code. I might consider trying this out for a project. It means I need to use cloudflare? I wonder if in the future, this could become more standard, and one could do something similar on their own infrastructure (maybe such a solution already exists, open sourced somewhere?)

Re: Workers Durable Objects Beta: A New Approach to Stateful Serverless

#80

Post by ignoramous »

kentonv wrote: post #21
ramchip wrote: post #18

> I'm going to be honest: naming this product was hard, because it's not quite like any other cloud technology that is widely-used today. Perhaps I'm missing something important, but isn't this quite similar to Orleans grains and other distributed actors?

"Actors" was actually one of the names we used internally for a long time (it's still all over the code), but eventually decided against because we found that people familiar with the Actor Model actually expected something a bit different, so it confused them. But yes, the basic idea is not entirely new. For me, Durable Objects derive from my previous work on Sandstorm.io, which in turn really derives from past work…

> ...we found that people familiar with the Actor Model actually expected something a bit different

I haven't done any programming with Actors per se but after skimming over its Wikipedia entry and other blog posts, Durable Objects does sound a lot like Actors to me.

Genuinely curious: What were some glaring differences that you were made aware of that led to not naming it Actors?

Thanks.

Post reply on HN