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.
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.
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.
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.
It is reassuring to hear that, could this feature in the docs somewhere? For example when I'm researching this issue this is what comes up as the first result.
Workers Free Tier fail modes are straightforward and preferable for some of the scenarios I would use them for, but KV is only enabled by using Bundled.
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).
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