In part 2 of this series about Temporal I want to dive deeper into some of the details involved in making workflows actually run and run properly.

Diving into:

(See here for part 1)

Temporal is gaining traction spearheading a new generation of Workflow tools/frameworks. Namely Durable Execution frameworks. Unlike most Workflow tools/frameworks, Durable Execution frameworks take a code-centric approach (no external models) meant to assist the developer in building complex Workflows (Sagas) that can take anywhere from seconds to months. There is no limit. Promising out-of-the-box support for (re)starting Workflows from exactly where they were (upon failure) based on managed event-sourced state management. Said to support a wide-range of use-cases from multistep financial processes to ML-pipelines in the wild.

From a 1000-feet view it seems like a Durable Execution framework like Temporal could indeed be the first developer-friendly generation of Workflow engines to assist a wide variety of long-running processes.

So join me on this journey and let’s find out if it is truly possible to write production-grade long-running processes in a non-evasive developer-friendly manner by asking my favorite architecture question…​

Will it Poker?

The purpose of Open Authorization 2.0 (OAuth 2.0) is to give an application (the "Client") limited access to your data at another service (the "Resource Server"), without having to give your password to that application. When OIDC is added Single Sign-On (SSO) is supported as well. The flow of these protocols can nicely be shown in a UML Sequence Diagram.

Sometimes when you upgrade your application the new version does not work correctly, and you need to downgrade. When you are unlucky you did some changes in your database that cannot be undone. In that case you need to restore the database from a backup, which is usually quite cumbersome and time-consuming. How nice would it be if you could just run an undo script which is much more light weight. This blog describes how you can do that using Flyway.

Nushell has the in operator to check if a value is an element of list. With the same in operator you can check if a string is a substring of another string. And finally you can use the in operator to check if a key is in a record. When you use the operator the value you want to check is defined before the operator and the list, other string or record is defined after the operator.
The not-in operator is the opposite of the in operator and checks if a value is not in list or other string or key in a record.
It is also possible to use the has and not-has operators to do the same checks, but the value you want to check is set after the operator. The list, other string or record is set before the operator.