Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- In what sense are these durable, given that they restart from the beginning if the server process crashes?by immibis
- Because the finished steps have their state stored so they don't repeatby adammarples
- Really cool! How does it compare to DBOS ? https://docs.dbos.dev/architectureby oulipo2
- I'm sure with time DBOS will be great, I just did not have a lot of success with it when I tried it. It's quite complex, the quality of the SDKs was not overly amazing (when I initially used it, it had a ton of dependencies in it) and it just felt early.
- Did anyone have a new approach to do this kind of transactional workflow? I heard that Saga patterns also define invertibility as well but I want a more general framework that also does all of this in one.
Also, I noticed how durable execution actually have so much to do with Continuation-passing style, is my intuition correct?
by stevefan1999 - I think it's a brilliant idea. Absurd can be a very good match to highway_dsl as well (which is a domain-specific-language, for workflows)
https://github.com/rodmena-limited/highway_dsl?tab=readme-ov...
by rodmena - This is pretty great! The main thing you need for durable execution is 1) retries (absurd does this) 2) idempotency (absurd does this via steps - but would be better handled with the APIs themselves being idempotent, then not using steps. Though absurd would certainly _help_ mitigate some APIs not being idempotent, but not completely).by eximius
- > idempotency (absurd does this via steps - but would be better handled with the APIs themselves being idempotent, then not using steps
That is very hard to do with agents which are just all probabilistic. However if you do have an API that is either idempotent / uses idempotency keys you can derive an idempotency key from the task: const idempotencyKey = `${ctx.taskID}:payment`;
That said: many APIs that support the idempotency-key header only support replays of an hour to 24 hours, so for long running workflows you need to capture the state output anyways.
- FYI. Highway DSL now fully supports Absurd. Specs: https://github.com/rodmena-limited/highway_dsl/blob/main/spe...by rodmena
- And here is the Python Client for Absurd:
https://python-absurd-client.readthedocs.io/en/latest/quicks...
by rodmena - Armin, I managed to review absurd.sql and the migrations. I am so impressed that I am rewriting the state management of my workflow engine with Absurd. Just wanted to thank you for sharing it with us. I'll keep you posted of the outcome.by rodmena
- Somebody said this the other day on HN, but we really are living in the golden age of Postgres.by saadatq
- Wow. Everything old is new again. I built a business state machine for a bespoke application using Oracle 8i and their stateful queues back in 2005. I had re-architected a batch-driven application (which couldn't scale temporally i.e. we had a bunch of CPU sitting near idle for a lot of the time), and turned it into an event driven solution. CPU usage became almost a horizontal line, saving us lots of money as we scaled (for the record, "scale" for this solution was writing 5M records a day into a partitioned table where we kept 13 months of data online, and then billed on it). Durable execution was just one of the many benefits we got out of this architecture. Love it.by phs318u
- It's quite funny in a way for me because even back in the Cadence days I thought it was the hottest shit ever, but it was just too complex to run for a small company and cadence was not the first (SWF and others came before). It felt like unless you had really large workflows you would ignore these systems entirely. And now, due to the problems that agents pose, we're all in need of that.
I'm happy it's slowly moving towards mass appeal, but I hope we find some simple solutions like Absurd too.
- I've been keeping an eye on this space for awhile as it matures a bit further. There's been a number of startups that have popped up around this - apart from Temporal and DBOS, Hatchet.run looked interesting.
I've been using BullMQ for awhile with distributed workers across K8 and have hacked together what I need, but a lightweight DAG of some sort on Postgres would be great.
I took a brief look at your docs. What would you say is the main difference of yours vs some of the other options? Just the simplicity of it being a single sql file and a sdk wrapper? Sorry if the docs answer this already - trying to take a quick look between work.
by mfrye0 - > I took a brief look at your docs. What would you say is the main difference of yours vs some of the other options? Just the simplicity of it being a single sql file and a sdk wrapper? Sorry if the docs answer this already - trying to take a quick look between work.
It's really just trying to be as simple as possible. I was motivated by trying to just do the most simple thing I could come up with after I did not really find the other solutions to be something I wanted to build on.
I'm sure they are great, but I want to leave the window open to having people self host what we are building / enable us to deploy a cellular architecture later and thus I want to stick to a manageable number of services until until I can no longer. Postgres is a known quantity in my stack and the only postgres only solution was DBOS which unfortunately did not look ready for prime time yet when I tried it. That said, I noticed that DBOS is making quite some progress so I'm somewhat confident that it will eventually get there.