The name “Durable Object” suggests that they store objects durably but the documentation, which I would like to link to :), says that state is lost if an object is evicted from memory.
The Hibernatable API addresses persistence of WebSocket connection state across evictions. The documentation states that, if an object is evicted from memory, the Durable Object’s constructor is invoked. The durability does not seem to span evictions yet, even if writes use the transactional API to persist data.
If this is correct, it seems best to preserve per-connection state that cannot be easily re-constructed in KV, D1 or some other external, resilient repository for now. I have seen projects that do this, but they don’t justify the choice. It seems a Durable Object currently resembles an in-memory store along the lines of Redis. Does this seem accurate? If so, perhaps transactional writes could optionally take a little longer to persist to durable storage. Writes are relatively uncommon for many apps and it might reduce costs for some.
The cloudflare workers-chat-demo states that chat history is “stored in durable storage”. It is assuming that the ChatRoom durable object’s “storage” variable is durable. Perhaps it should be using KV or D1 or some other service for storage if evictions can still occur and the object state does not persist across evictions. If evictions don’t occur anymore, perhaps the Hibernatable API is no longer necessary?
It would be nice if links to GitHub projects were allowed btw. Not sure why the editor has a link icon but the system, which is otherwise quite amicable, won’t permit links in submissions.