Hello, no you are definitely the target users. Anyone who needs to build long running business/application/process is the target user of iWF.

You are right, there were too many context about Cadence/Temporal in the README. I just made a update to move a lot of them to wiki just for the Cadence/Temporal users.You can check https://medium.com/@qlong/iwf-vs-other-general-purposed-work... for comparison with other workflow engines.

I will move the G docs and slides later.

Thanks for the suggestion!

i wrote a longer intro to the problem domain of Cadence/Temporal here in case it helps: https://www.swyx.io/why-temporal

and you can browse the Temporal youtube (https://www.youtube.com/@Temporalio) for anywhere from 2min - 2hour explainers of what Temporal does, what you use it for, how it works.

(disclaimer - former employee. still a big fan of the entire category - every company needs a workflow engine for anything long running (usually the most valuable/hard-to-test async stuff), and your choices are between build a bad one yourself or take the most industry battle tested one - uber, airbnb, coinbase, netflix, stripe, etc - off the shelf and get tooling/docs/ecosystem/maintenance for free)

What do you think about using Cloudflare durable objects for long running stuff instead of something like temporal?

iWF is not just persisting states, but also able invoking/executing states, searching for attributes(like unlimited database indexes), durable timer, resetting workflows etc.

Without Temporal/Cadence, it's 100+ harder to implement iWF. Even using SWF/Azure durable function is possible to build iWF, Cadence/Temporal is much more powerful than the other two(e.g. no reset workflow, search attributes)

durable objects are just a persistence layer, you still need scheduling, state machine, introspection/querying/analytics (incl search attributes in temporal terminology), signal response, batch transactions etc etc. so you have to understand/internalize that workflow engines are a layer of abstraction above that and if you don't you're going to be handrolling one without knowing it.

Right.. the tricky thing is when you think your use case is relatively basic, you're a one person team, and you want to decide whether to pull in such a powerful tool, and deploy and manage it.. or take a more DIY approach, have it all just run on demand in the cloud, and not have to learn a bunch of APIs and concepts as they're described by Temporal etc.

cloudflare alarms seem like a decent solution for scheduling. If you want a state machine, you can just use a state machine (xstate).

The durable object primitives are more limited, but therefor seem a little easier to get your head around if you don't need all sorts of complex signalling.

introspection / analytics is obviously a pain to have to deal with yourself. I guess you'd end up saving the state to a database after any action. And you could probably get a reasonable little analytics dashboard fairly painlessly by chucking something like appsmith in front of it?

You can absolutely approach it that way, but AFAIK those are highly integrated but still discrete solutions. Temporal provides a unified model for these things instead of requiring people to stitch things together themselves. Due to Temporal handling all of the things, you also get additional value out of the centralization (you can see the live source of truth for any running business process).

I do agree that Temporal is heavyweight both in terms of the learning curve and deployment requirements.

For disclosure I’m the Head of Product at Temporaly. We know things can be better and we are working on it.

I can't wait for Temporal's cloud offering to work for the "small dev". It would be so wonderful to only need to worry about the learning curve of using the tool, and not the deployment + cost. It would be great to be able to reach for it for any little project that needed robust persistent workflows.

Completely and totally agree! Don't lose faith we will get there I promise.