Looks great but one of the common problems with the virtual actor model is state query. It's all well and good to have nice separated state dbs but for most use cases that means further double up on storing the state again in another database that can query it. I don't think anyone has come up with a nice solution for this problem without using a loose document database, but even then actors can change their schema.
Perhaps emitting versioned domain events transactionally with the actor state is an option without prescribing an exact solution.
This is a great comment! We actually get this a lot.
Since we are so early, we can build this the right way. I agree, I think we need something you can set up to sync to a data lake. I started really simple with exporting at certain times, but I think there is more to do here.
I really want to nail this part of the experience. I agree, it is a big sticking point
How do you compare to Azure Durable Functions, Temporal, AWS Lambda Durable Functions?
Can't Durable Entities meet the same use cases?
EDIT: Of course I am not talking about the difference in OSS vs not. Rather I'm interested in the difference in use cases and capabilities. Some of the aforementioned have ways to run things locally as well, though they are designed as distributed cloud-based PaaS services.
The latency on those listed products is high because it's async queue based processing. This on the other hand should have predictable low latency as the placement of the live object is known.
Hey! so celld is a direct port of Durable Objects.
We are actually a different API. I come from writing swift for 7 years (I was at apple) and really thought they nailed the actor model so modeled ours similarly.
Also, we make it really easy to configure each actors compute with just a decorator. So if you want to do something beefy like store file directory in an actor you can increase the memory to 4GB and you are good to go!
Perhaps emitting versioned domain events transactionally with the actor state is an option without prescribing an exact solution.
Since we are so early, we can build this the right way. I agree, I think we need something you can set up to sync to a data lake. I started really simple with exporting at certain times, but I think there is more to do here.
I really want to nail this part of the experience. I agree, it is a big sticking point
Also are you able to self-host this outside of GCP (from the docs it seems like it is locked to GCP but I'm not that familiar with it so maybe not)?
Can't Durable Entities meet the same use cases?
EDIT: Of course I am not talking about the difference in OSS vs not. Rather I'm interested in the difference in use cases and capabilities. Some of the aforementioned have ways to run things locally as well, though they are designed as distributed cloud-based PaaS services.
I mean we have https://github.com/denoland/celld - with a known good open source history. Durable writes there are as low as 1ms.
Want to make this the best product possible
We are actually a different API. I come from writing swift for 7 years (I was at apple) and really thought they nailed the actor model so modeled ours similarly.
Also, we make it really easy to configure each actors compute with just a decorator. So if you want to do something beefy like store file directory in an actor you can increase the memory to 4GB and you are good to go!
Happy to go into more detail here as well!