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

41–50 of 58 posts

Re: Durable Objects in Production

#41

Post by kentonv »

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.

Workers KV is still better in many use cases. Durable Objects are the right choice when you need strong consistency. KV is the right choice when you want world-wide low latency access to the same data. Note that these two advantages are fundamentally opposed; it is physically impossible to simultaneously have strong consistency and worldwide low-latency access to a single piece of data. So, this will always be a trade-off.

Note that you could build KV on top of Durable Objects, by implementing your own caching and replication in application logic running in Durable Objects. On the other hand, you can't implement Durable Objects on top of KV; once you've lost strong consistency, it's hard (impossible?) to get it back. So in that sense, Durable Objects are "strictly superior". But in a practical sense, you probably don't really want to do the work to implement your own KV store on top of Durable Objects; it's probably better to just use KV.

Re: Durable Objects in Production

#44

Post by eastdakota »

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.

We don’t charge for malicious traffic like DDoS. Compares favorably to other cloud providers who do.

Re: Durable Objects in Production

#45

Post by fiddlerwoaroof »

haneefmubarak wrote: post #33
fiddlerwoaroof wrote: post #30

Earlier quoted context omitted.

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@)?

There’s one in my profile.

Re: Durable Objects in Production

#46

Post by nmjohn »

eastdakota wrote: post #44
a_imho wrote: post #38

Earlier quoted context omitted.

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.

We don’t charge for malicious traffic like DDoS. Compares favorably to other cloud providers who do.

You don't charge for worker invocations on a L7 DDoS? How do you determine which requests to charge for and which to not charge for?

Or is the claim your DDoS protection is good and accurate enough that there are 0 worker invocations to charge for because they all get blocked?

Re: Durable Objects in Production

#47

Post by Scarbutt »

kentonv wrote: post #41
a_imho wrote: post #38

Earlier quoted context omitted.

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.

Workers KV is still better in many use cases. Durable Objects are the right choice when you need strong consistency. KV is the right choice when you want world-wide low latency access to the same data. Note that these two advantages are fundamentally opposed; it is physically impossible to simultaneously have strong consistency and worldwide low-latency access to a single piece of data. So, this will always be a trad…

What's the size limit of a single 'Durable Object' ?

Re: Durable Objects in Production

#48

Post by frakkingcylons »

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…

I was struggling to wrap my head around Durable Objects, this was very useful.

Re: Durable Objects in Production

#49

Post by kentonv »

Scarbutt wrote: post #47
kentonv wrote: post #41

Earlier quoted context omitted.

Workers KV is still better in many use cases. Durable Objects are the right choice when you need strong consistency. KV is the right choice when you want world-wide low latency access to the same data. Note that these two advantages are fundamentally opposed; it is physically impossible to simultaneously have strong consistency and worldwide low-latency access to a single piece of data. So, this will always be a trad…

What's the size limit of a single 'Durable Object' ?

There's no hard limit, but given that a single durable object is single-threaded, storing a huge amount of data in a single object may make it hard to access that data. Also, the system may be less likely to migrate huge objects to move them closer to their users. So, we recommend aiming for small, fine-grained objects, kilobytes to megabytes in size. But there's nothing fundamentally preventing an object from growing to multiple gigabytes.

Re: Durable Objects in Production

#50

Post by kentonv »

nmjohn wrote: post #46
eastdakota wrote: post #44

Earlier quoted context omitted.

We don’t charge for malicious traffic like DDoS. Compares favorably to other cloud providers who do.

You don't charge for worker invocations on a L7 DDoS? How do you determine which requests to charge for and which to not charge for? Or is the claim your DDoS protection is good and accurate enough that there are 0 worker invocations to charge for because they all get blocked?

We aim to block attack traffic. If we fail to block an attack and you get charged for it, file a support request to ask for a credit.
Post reply on HN