I was hoping for some updates to Durable
I was hoping for some updates to Durable Objects announced this week. Have all the announcements been posted now? Is there anything for DOs that I missed?
13 Replies
Not necessarily anything specific (though alternate pricing for websocket use-cases would be amazing), but generally I'm excited around the space and interested in any new advancements with Durable Objects.
Also, everything shared has been awesome. What a great week! Thank you team
would also loved to have seen some form of hibernation launch.
Yes, eliminate the per-message charge for websockets and add a hibernate API and we're golden. Then we can handle the two awkward uses cases of lots of little messages that take almost no CPU/Memory over websocket and quiet long-running sockets with little or no traffic over them.
Make the per-message charge be a per-connection charge and charge every time a connection is established or hibernate wakes back up.
that would be great, but personally i'd rather them launch network-only http-streams-as-a-service.
adding APIs to opt-out of available functionality feels like a smell to me.
I like this idea:
We've also considered billing for Durable Objects based on active CPU time, plus a small WebSocket connection charge (per minute) whenever a WebSocket connection was open to a Durable Object. This charge would be much smaller than the current duration charge.from https://discord.com/channels/595317990191398933/773219443911819284/831990845523623977 It feels like the simplest billing, even if it is harder to project without building out test cases.
totally, this is basically the AWS billing model.
Except for the "much smaller than the current duration charge" 😄
i just think that's tricky to implement well.
like, CPU is one thing, but what about memory?
how can they spin down the DO if there's still stuff in memory?
Our phones persist app memory to disk while it is not active. Perhaps it could be done that way, persisted to cheaper disk storage while the DO is ejected. I suppose that's the same as using DO storage, but wouldn't that be cool if it automatically persisted your in-memory state to storage?
i mean, memory can contain things that aren't serializable.
functions, closures, etc.
Good point. I've not done any mobile development, but I assume they have a specific way they handle this. I suppose the DO way to handle it is putting everything in storage explicitly and loading it from there?
If you used up 100MB of memory though, that would be very expensive (relatively speaking) for every in-memory update to persist.
Usually disk is cheaper than memory, but the cost model here is not. Probably because of the redundancy and consistency guarantees for DO storage.
this is why i think it would be cleaner to decouple storage and compute from network.
let {readable, writable} = env.durableStream.create()
for example. that would create two URLs. send the readable URL to the client as a WS endpoint, store the writable URL in DO storage or something to send POSTs to.All the announcements have been posted there wasn't anything with regard to DO this week. As far as billing changes I wouldnt really get your hopes up because it probably takes a lot of back and forth between multiple departments and then having to handle the subscription changes etc etc. If anything does change it probably wont be for a while imo