5 ms·

Cloudflare's Durable Multiplayer Moat

• chrisjj 3y ago
  How durable is this durable? E.g. does CF promise to persist for X months since last access?
  • paulgb 3y ago
    CF doesn’t make any guarantees about the durability of in-memory state, but state stored in the durable KV store that each object gets is persisted indefinitely. A useful pattern is to use the in-memory state as a cache, loading the state from the KV on initialization, and then only hitting the KV again for writes.
    • chrisjj 3y ago
      > state stored in the durable KV store that each object gets is persisted indefinitely. So zero durability one can rely on then. Making me much doubt the value of this "it allows you to retain in-memory values (as class fields) across invocations" Thanks.
      • paulgb 3y ago
        The best approach is to treat it as a cache for reads. You do still need to have initialization logic to restore in-memory state from the KV store, but since that logic isn't run on the vast majority of requests, you can afford for that initialization logic to be more expensive. There's also plenty of state (live cursor positions, for example) that you may want to have in-memory, but you don't want to be durable. The advantage of DOs is that you get to make that choice, instead of the platform insisting that any state passed on to the next invocation be stored durably outside the process.
        • chrisjj 3y ago
          Figures, but then the gain is just performance. Not functionality as trumpeted.
• crabmusket 3y ago
  This is a really great, concise summary of the significance of Durable Objects and the lack of alternatives. It seemed like every six month there was a new "we help you build realtime apps" product popping up, and they were all based on Durable Objects under the hood. PartyKit had talked before about maybe hosting workerd themselves to provide an actual alterative provider, but I assume that's off the cards now with the acquisition.