Comments to "Temporal: Open Source Workflows as Code"

[mikhailshilkov]

Add your comment to Temporal: Open Source Workflows as Code.

The comments will be displayed directly on the page. I may edit or merge your comments in a non-significant way to make sure they are displayed properly on the website.

[MedAnd]

Any chance you can compare with https://github.com/dapr/workflows in a future post 🙂

[mikhailshilkov]

Thanks! I've never used Dapr Workflows but I'll keep them in mind.

It looks like it's a Dapr wrapper around Azure Logic Apps runtime. This means that the main difference to me would be the definition language: Logic Apps are defined as JSON files vs. Temporal using general-purpose programming languages like Go.

[meiliang86]

Check out https://cadenceworkflow.io/ as well. We are also in active development :)

[rukhsarahmad-gep]

JSON based Vs general-purpose programming? - in the case of a low code platform and customer needs to define the workflow.

[ivastly]

You are saying in the article that "The new execution has the history of previous runs, so it replays to the point where the last execution stopped and takes the next step."

Can you shed some light on how exactly it happens in the correct way? Because if it would just "replay", then all previous actions were executed. So, the user were put on trial subscription again. I expect that the execution magically continues from the exact point after sleep call, just like you spent a month waiting on debug breakpoint. But how is it possible? What about state of local variables?

[mikhailshilkov]

There's no way to continue the execution from the exact point where it stopped. So, it does re-execute the workflow function from the beginning.

However, while doing so, it inspects the history of past executions. If the history says that a given activity (e.g., onboardToFreeTrial) was already executed, the replay will not call the activity again but will "short-circuit" and return the result directly.

Similarly, the second (and 3rd, and 4th) execution of the same sleep(60) call won't sleep again but would return immediately, knowing that sleep is already finished. The magic is in the Workflow implementation, which can inspect the past history and decide whether to call a given activity for real or return its result from the previous execution.

That's why workflows must be deterministic. If you run some code with arbitrary side-effects from within the workflow function, it will actually run N times, so this is discouraged in practice.

[Alex2357]

I wonder how changes to the workflows should be implemented. Let's say business comes up with a new requirement to add/remove some acitvities? Is there a new workflow or a new version of workflow should be added? What approaches used to resolve this?

[mikhailshilkov]

Great question. As I understand it, the new workflow implementation should be able to understand which version the current execution belongs to and "route" activities based on this version. You drain out all old workflow executions until the old version is fully gone and then you can remove the per-version routing.

See more details in the Versioning doc.

[wolvever]

Thanks! I've never used Dapr Workflows but I'll keep them in mind.

It looks like it's a Dapr wrapper around Azure Logic Apps runtime. This means that the main difference to me would be the definition language: Logic Apps are defined as JSON files vs. Temporal using general-purpose programming languages like Go.

Dapr workflow is using durabletask-go behind the scene, which is an open source implementation of durabletask in golang. And now dapr workflow is no longer just a wrapper for Azure Logic Apps. Can you compare durabletask-go and Temporal ?