Ohhh gotcha, yeah in that particular usecase of mainly having push updates, I totally get that

How are durable object

list

operations priced? If I list 100 values will this count as 100 reads?

Any update on the billing of idle websocket connections to DO. if these keep the DO up and get billed normally, then this will encourage reducing the number of DO thus negating the benifit of having distributed system.

Also will DO be billed as 128MB even if they use less memory?

perhaps this is the downside of the convenience of coupling network and compute, but this could make a lot of use cases untenable for DO. consider a digital photo frame that connects via WS and (infrequently) receives images via HTTPS. the daily baseline cost for that connection would seem to be as follows: AWS API Gateway ($0.25 / million minutes) $0.25 / 1000000 * 60 * 24 = $0.00036 Cloudflare Durable Objects ($12.50 / million GB-seconds) $12.50 / 1000000 * .128 * 60 * 60 * 24 = $0.13824 basically, for workloads light on compute and concurrency, Cloudflare seems orders of magnitude more expensive than AWS. most of the workarounds i can think of to mitigate this (multi-tenant DOs, maybe one per PoP?) diminish the convenience of DO isolation/portability, but maybe that's just the nature of the tradeoff? is the best bet in this case to have one DO for networking and one for storage/compute?

Did

waitUntil

make it into ES module workers yet? 😬

It's treated similar to a scan - if your list returns 100 KB of data, you'll be billed for 25 reads.

Question can websockets be established between multiple DOs?

Or is using fetch just fine

Example. I have many users with balances, each user is a DO, say there is 10 000 users. Then they interact with shared resources, like chatrooms. Say there are 100 chat rooms. The chatrooms then send back updates to each users DO if they received extra money from the chat ( this is not dating/OF)

Should I establish WS here, or is using fetch just fine to update the user DOs, there maybe quite alot of updates

Like will this be hit with a price per request?

we're aware of this - one option we've considered is having a way to hibernate websocket connections, so that you won't be billed for them after some idle period. we've also discussed changing our pricing for websockets specifically. we're trying to balance DO complexity + pricing model complexity, but for the idle websocket use case we have work to do.

How expensibe is it to idle a websocket 24/7?

That's my exact use case too

$0.13?

Is setTimeout valid inside a DO?

Say the pattern of batching diff. Example, a bunch of updates come, instead of sending each update 1 by 1 to each subscribed user, the updates get pushed to a queue, then a setTimeout 100ms into the future gets set which flushes the queue

It seems its allowed in the request context and a websocket request context will not close for a while

Basically is it possible to have a Tick inside a DO? Without a single request connected to it

Something nice would be actually is it possible now? To access a durable objects storage from outside the DO as readonly

honestly if i can use one DO as a long-running stateless message broker that delegates to other DOs for per-object compute/storage, that might be good enough for my use case. i favor this kind of composition over the complexity involved in pricing carveouts for websockets, especially when there are other idle situations (setTimeout, EventSource or other non-WS long-lived HTTP).

very basic question..what would be the best way to add KV support to the chat demo? Wanting to save some of the requests to see whats going on and tweak it but I can't seem to even get KV working. Any suggestions would be great

did you ever find a solution to this...was wanting to do some KV storage modifications in the chat demo but seems to have hit a wall.

Yes - are you wanting to do ‘normal’ KV operations or use that lib to serve static files?

something nice would be event subscribers on the KV Storage or accessing the DO storage as READONLY outside the DO

its too inefficient to send a FETCH to a DO just to have it do a storage.list

that wont scale at all

Yes, using setTimeout like that will work. You can't set them indefinitely far in the future if no requests are coming in and no websockets are connected, but if either is true or you're setting timeouts for less than 30 seconds in the future you'll be ok

There shouldn't be anything stopping you from using KV from within the chat demo -- just add the binding to wrangler the binding name will show up on the

env

variable in your fetch handler. As for using the asset-handler library, you may have to tweak it to make it usable without a

FetchEvent