4 ms·

The one feature I miss the most on Cloudflare Workers/Durable Object is TrueTime. Durable Objects are fundamentally replicated state machines with a nice JavaS

The one feature I miss the most on Cloudflare Workers/Durable Object is TrueTime. Durable Objects are fundamentally replicated state machines with a nice JavaScript API. You can build an automatically sharded (yet correct) Kafka API implementation, or even an entire Spanner-style distributed database on Workers, given the right primitives (DO + TrueTime).

bastawhiz 4y ago
DOs aren't distributed, they're guaranteed to be a single instance of any DO running in exactly one data center, running ~single threaded. So TrueTime doesn't seem helpful, since Date.now() in the worker will always just be one time. TrueTime would offer you a primitive to do the work that Cloudflare gives you for free by virtue of using their infrastructure: would you rather have the primitive and do it yourself? Or would you rather just have the system do that for you so you don't need to think about coordinating a distributed system?
- losfair 4y ago
  TrueTime is an efficient primitive to ensure external consistency across multiple consensus groups, not within one group. The current DO infrastructure does not give the TrueTime guarantees for free: you cannot do transactions across two or more durable objects, and the max throughput within a transaction domain is limited to what a single V8 isolate can handle sequentially.
  - bastawhiz 4y ago
    DOs are arguably the wrong primitive if you're looking to do transactions across more than one of them. They're essentially partitions, which is how this project uses them. If you do transactions across more than one, you are still making blocking, synchronous requests across DO instances which can be across N data centers. You can't really implement locking for blocking writes if you want to implement transactions at a layer above DOs: short of implementing a spin lock (very expensive with workers), you don't have a way to wait for an ongoing transaction to complete. Which is to say, if you had a way to implement transactions with TrueTime in Workers, you could just use the standard KV store and avoid DOs entirely, no? The great part about workers is that you don't pay for idle time—if you're implementing your own locking, you're not able to yield the event loop back to CF. At that point, you've lost most of the benefit of being at the edge (you're making blocking cross-DC requests) and most of the cost benefits of Workers.
    - kentonv 4y ago
      You can implement synchronization across DOs, but the application has to coordinate it. E.g. you could implement two-phase commit to get strongly consistent semantics (with the possibility of temporary unavailability if the network between the objects is partitioned at the wrong moment). Or if your application can tolerate eventual consistency, consider using CRDTs for partition tolerance. These things require some care to get right, but not a huge amount of actual work, compared to the challenge of implementing lower-level consensus and replication that DO takes care of for you.

bastawhiz 4y ago

DOs aren't distributed, they're guaranteed to be a single instance of any DO running in exactly one data center, running ~single threaded. So TrueTime doesn't seem helpful, since Date.now() in the worker will always just be one time. TrueTime would offer you a primitive to do the work that Cloudflare gives you for free by virtue of using their infrastructure: would you rather have the primitive and do it yourself? Or would you rather just have the system do that for you so you don't need to think about coordinating a distributed system?

losfair 4y ago
TrueTime is an efficient primitive to ensure external consistency across multiple consensus groups, not within one group. The current DO infrastructure does not give the TrueTime guarantees for free: you cannot do transactions across two or more durable objects, and the max throughput within a transaction domain is limited to what a single V8 isolate can handle sequentially.
- bastawhiz 4y ago
  DOs are arguably the wrong primitive if you're looking to do transactions across more than one of them. They're essentially partitions, which is how this project uses them. If you do transactions across more than one, you are still making blocking, synchronous requests across DO instances which can be across N data centers. You can't really implement locking for blocking writes if you want to implement transactions at a layer above DOs: short of implementing a spin lock (very expensive with workers), you don't have a way to wait for an ongoing transaction to complete. Which is to say, if you had a way to implement transactions with TrueTime in Workers, you could just use the standard KV store and avoid DOs entirely, no? The great part about workers is that you don't pay for idle time—if you're implementing your own locking, you're not able to yield the event loop back to CF. At that point, you've lost most of the benefit of being at the edge (you're making blocking cross-DC requests) and most of the cost benefits of Workers.
  - kentonv 4y ago
    You can implement synchronization across DOs, but the application has to coordinate it. E.g. you could implement two-phase commit to get strongly consistent semantics (with the possibility of temporary unavailability if the network between the objects is partitioned at the wrong moment). Or if your application can tolerate eventual consistency, consider using CRDTs for partition tolerance. These things require some care to get right, but not a huge amount of actual work, compared to the challenge of implementing lower-level consensus and replication that DO takes care of for you.