Comment by stavros | Hacker News Reader

Comment by stavros | Hacker News Reader

We were just looking for something similar to this to run workflows at $JOB and decided to build our own in the end, because nothing we found fulfilled our requirements.

A few questions, just in case:

1. Does Windmill support long-running workflows? Our use case has our customers being in a workflow for years (as long as they have a relationship with us) and events moving them around states.

2. Does it support rule-based state transitions? Everything I've seen is "when this webhook comes, go to that state", but we want something that will trigger the evaluation of a set of rules (with an event or webhook), and the rules will contact APIs to judge whether everything is satisfied for a transition to some next state.

3. Does it support synchronous calls? We usually want the customer to ask "OK where am I now?" and the system to trigger evaluation, transition them to the state they should be in, and tell them where they are. This is for use cases like the website asking "the user has just submitted the data we wanted, where should I redirect them now?".

Those were the biggest things we couldn't find.

1. Yes there are no time limits for workflows and there is no cost to keep a workflow suspended. It will just be scheduled to be reactivated in the future

2. The webhook can contain a payload, and you can but the suspend step into a for-loop. You could literally say, for-loop forever the suspend until the result of the suspend step (which can be the result of the evaluation of the webhook payload by your rule is true). For that, you will need to use another primitive that we expose which is "Break" that will break out of the for-loop

3. I'm a bit unsure of the term synchronous call. We have a long list of APIs https://app.windmill.dev/openapi.html#/ and you fetch the status of the flow or trigger a flow in a synchronous http webhook to wait for the result. As to force the state of the workflow. We do not expose something like that but it could be added easily.

Happy to chat if we could be a good fit for your needs: ruben@windmill.dev

Thank you! It doesn't sound like an exact fit but Windmill looks great in general, well done!

For the second point, the idea is that we don't want to rely on webhooks at all, except as evaluation triggers. The rules are built in to each state, so even if we've missed a webhook/event, the customer can still proceed.

For an example, one of our flows requires the user to have filled out a consent form in the last three months. As I understand it, with your design, we need to send a webhook when a user has given consent, and then we can proceed to the next state, so we'd have to somehow check for previous consent in some different state? With our design, when the user reaches the state, the rules will be evaluated, and "has given consent within the last three months" will be true, and the user will proceed to the next state without ever seeing the consent form.

For the synchronous bit, it kind of follows from the above feature, and it is so we evaluate state transitions while the user is waiting. We run the workflow synchronously, in the request (since no workflow needs external events to continue), and return the new state to the user.

Since this is synchronous, it avoids races or long waits for events to be delivered.

Thanks for listening, maybe you'll find some of the above helpful in your design!

Makes sense. I understand the synchronous part now. I think there are ways to achieve the same benefits with an asynchronous system but if what you have works, no point changing it!

Reply on news.ycombinator.com