I’m trying to learn Temporal and “unlearn” some other workflow engine - and I’m confused about when we code our business logic as an Activity.
The docs are clear and really deep - so thanks for that - but they seem to indicate that we reserve Activities for things like I/O and other side-effects. Am I reading that right? In other words, I don’t need to use Activities when I have a workflow made up of say 15 tasks, with conditional/flow logic but NO calls to outside services, I/O or similar.
I come from BPMN-based workflow engines and was really happy to see that Temporal supported code-based definitions, but I really am struggling to map where the code goes. In my BPMN flows I basically passed a data object through each task in the flow, persisting the data at the end of that flow… so the only I/O happened in the very last task in most cases. So, other than writing to my database at the end, do I use Activities at all?
All the examples I can find show all of the “work” of the workflow done in Activities. Is there an example, in any language, that I should be looking at that includes a multi-step workflow where each step is what I would loosely call a “pure function”?
The other reason to have an activity would be a very computationally intensive function. Besides that I/O is the main purpose for them.
In my BPMN flows I basically passed a data object through each task in the flow, persisting the data at the end of that flow… so the only I/O happened in the very last task in most cases.
What is the purpose of a workflow that doesn’t perform any I/O? Your BPMN flows sound like pure functions that don’t benefit from the durability and recoverability of workflows.
I have a workflow made up of say 15 tasks,
What are these tasks if they are not doing any I/O?
Interesting. Ok, with other workflow systems we used the models to break flows down so we could fully understand and optimize the flow of business logic. We used BPMN models and worked with business stakeholders to create differentiating processes… then we fed the models to the engine for execution… and that’s when things went sideways for us. Temporal’s approach of not using XML or some other intermediate notation is appealing.
I guess I’m just old school in my definition of what a workflow is. We have found that workflow models, paired with DDD concepts, have resulted in better decomposition and more effective long-term engagement with business stakeholders. Far better, for instance, than Agile stories that few people read or read consistently.
What I’m gathering from your response is that Temporal takes on the hard stuff and everything else is just code. Fair enough.
After posting, I found the Go Chekr sample, which was very helpful.