Rendered at 18:53:02 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
jeremycarter 1 days ago [-]
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.
thomask1995 1 days ago [-]
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
patcon 19 hours ago [-]
Love actor-based infra! can you compare/contrast this to cell.dev?
- built with running in sandboxes to give users more flexible CPU and memory settings per DO
- declarative SDKs in Typescript/Python
- generated type-safe clients (no outer worker needed)
- built in debugging UI
- durability guarantee is using GCS rapid or other cloud technology for fast writes without having to manage a fleet
Happy to go more in detail as well!
verst 1 days ago [-]
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.
behindsight 23 hours ago [-]
additionally keep in mind the "durable" in durable objects is not the same "durable" in those three you mentioned.
Cloudflare's equivalent for that is instead called "workflows" [1] for those resumable/retryable multi-step functions for durable execution.
(naming is kinda confusing, I had to build out a redundancy system across all these providers)
Olivier's comment seems to have been suppressed. Not sure why. reposting
thanks for the question verst. durable actors manages durable state, not durable execution. Azure Durable functions, temporal, aws lamda durable functions are for managing execution.
each actor has its own sqlite DB and runs on one host at a time. Clients call it via RPC or Websocket message, changing state and actor pushes state changes back to every client. product is more similar to cf durable objects or orleans.
i took a look at durable entities, state model is similar but they don't support websocket handling.
jeremycarter 1 days ago [-]
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.
verst 1 days ago [-]
I don't yet live in a world where my agents are fast enough where the cloud service latency matters :)
olism 1 days ago [-]
thanks for the question verst. durable actors manages durable state, not durable execution. Azure Durable functions, temporal, aws lamda durable functions are for managing execution.
each actor has its own sqlite DB and runs on one host at a time. Clients call it via RPC or Websocket message, changing state and actor pushes state changes back to every client. product is more similar to cf durable objects or orleans.
i took a look at durable entities, state model is similar but they don't support websocket handling.
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)?
thomask1995 1 days ago [-]
Hey! Yea we are a very different API from them. Closer to Cloudflare for sure.
Our biggest differentiator is the configurable compute. With our helm chart, you just add a decorator and can specify how much RAM, CPU etc... an actor class has.
We are pretty opinionated on how to host these. The helm chart gets you a fully horizontally scalable deployment.
m1117 1 days ago [-]
Great! Let’s have more cloudflare alternatives
patcon 19 hours ago [-]
solid agree! cloudflare has inspiring offline tooling, for sure, but OSS def better
thomask1995 1 days ago [-]
Yes! would love to know what you think.
Want to make this the best product possible
anilgulecha 1 days ago [-]
100ms for a write - not usable for anything beyond toys.
Hey! durable writes for celld (single node, wait for bucket) is 90ms. Documented pretty clearly on the landing page.
Celld is pretty cool in that you can configure a small fleet in the same VPS and get super fast durable writes (with a weaker guarantee). We are also going to allow you to tweak the durability guarantees so you can manage that trade off yourself!
anilgulecha 1 days ago [-]
> super fast durable writes (with a weaker guarantee)
Nope. you just run it on 2 VMs in same zone and get 1ms (ack on durable disk write).
I'm surprised at your technical language. Either you're ignorant of basics of how other key durable systems works, or you're misrepresenting a unnecessary worse case. Neither inspires confidence in your work.
thomask1995 24 hours ago [-]
I'm always keen to learn more!
Do you have a reproducible set up I can try out to see this latency? We would love to offer an option to have 1ms writes
anilgulecha 17 hours ago [-]
Cells documentation is good. I'd suggest pointing an agent to them and requesting a deployment setup for low latency. It should suggest 2 Vms in same AZ on a cloud of your choice - LAN setup.
handfuloflight 1 days ago [-]
How does it compare to celld?
thomask1995 1 days ago [-]
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!
Happy to go into more detail here as well!
steve_adams_86 1 days ago [-]
> I come from writing swift for 7 years (I was at apple) and really thought they nailed the actor model
Which actor models are you comparing to? What do you think of Erlang/Pekko/Pony?
I roughly understand their models but have never looked at Swift's. On the surface it looks like it borrows heavily from each of these (now that I'm looking) which sounds potentially awesome. I suppose I'm curious what you think makes Swift's model 'nailed' relative to alternatives.
It's pure curiosity. I love actor models and enjoy learning about the paradigm in general.
thomask1995 21 hours ago [-]
For me it was the decorator syntax + opting into "dangerous" things.
I love the idea of tossing a decorator and modifying the durability guarantees.
Also, swift @sendable is really sweet, also want to add that in and flag when state data is about to leave the actor.
Actors really were a life saver at Apple. Agents are like what threads were to us on iOS
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
https://celld.dev/
https://tlockney.github.io/celld-book/
https://noite.now/ https://github.com/kentcdodds/kody-celld
https://celld-operator.io/ https://ewhauser.github.io/celld-operator/
Here are some of our differentiators:
- built with running in sandboxes to give users more flexible CPU and memory settings per DO
- declarative SDKs in Typescript/Python
- generated type-safe clients (no outer worker needed)
- built in debugging UI
- durability guarantee is using GCS rapid or other cloud technology for fast writes without having to manage a fleet
Happy to go more in detail as well!
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.
Cloudflare's equivalent for that is instead called "workflows" [1] for those resumable/retryable multi-step functions for durable execution.
(naming is kinda confusing, I had to build out a redundancy system across all these providers)
1: https://www.cloudflare.com/products/workflows/
thanks for the question verst. durable actors manages durable state, not durable execution. Azure Durable functions, temporal, aws lamda durable functions are for managing execution. each actor has its own sqlite DB and runs on one host at a time. Clients call it via RPC or Websocket message, changing state and actor pushes state changes back to every client. product is more similar to cf durable objects or orleans.
i took a look at durable entities, state model is similar but they don't support websocket handling.
each actor has its own sqlite DB and runs on one host at a time. Clients call it via RPC or Websocket message, changing state and actor pushes state changes back to every client. product is more similar to cf durable objects or orleans.
i took a look at durable entities, state model is similar but they don't support websocket handling.
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)?
Our biggest differentiator is the configurable compute. With our helm chart, you just add a decorator and can specify how much RAM, CPU etc... an actor class has.
We are pretty opinionated on how to host these. The helm chart gets you a fully horizontally scalable deployment.
Want to make this the best product possible
I mean we have https://github.com/denoland/celld - with a known good open source history. Durable writes there are as low as 1ms.
Celld is pretty cool in that you can configure a small fleet in the same VPS and get super fast durable writes (with a weaker guarantee). We are also going to allow you to tweak the durability guarantees so you can manage that trade off yourself!
Nope. you just run it on 2 VMs in same zone and get 1ms (ack on durable disk write).
I'm surprised at your technical language. Either you're ignorant of basics of how other key durable systems works, or you're misrepresenting a unnecessary worse case. Neither inspires confidence in your work.
Do you have a reproducible set up I can try out to see this latency? We would love to offer an option to have 1ms writes
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!
Which actor models are you comparing to? What do you think of Erlang/Pekko/Pony?
I roughly understand their models but have never looked at Swift's. On the surface it looks like it borrows heavily from each of these (now that I'm looking) which sounds potentially awesome. I suppose I'm curious what you think makes Swift's model 'nailed' relative to alternatives.
It's pure curiosity. I love actor models and enjoy learning about the paradigm in general.
I love the idea of tossing a decorator and modifying the durability guarantees.
Also, swift @sendable is really sweet, also want to add that in and flag when state data is about to leave the actor.
Actors really were a life saver at Apple. Agents are like what threads were to us on iOS