For those not familiar with workflows as code, a workflow is a method that is executed in a way that can't fail—each step the program takes is persisted, so that if execution is interrupted (the process crashes or machine loses power), execution will be continued on a new machine, from the same step, with all local/instance variables, threads, and the call stack intact. It also transparently retries network requests…
Temporal .NET – Deterministic Workflow Authoring in .NET
41–50 of 51 posts
Re: Temporal .NET – Deterministic Workflow Authoring in .NET
#42We’ve been using temporal (the Python SDK) for some new projects at Internet Archive. It’s early days but we’re very excited. We run our own infrastructure, and we get more power-loss events or other intermittent issues than most. The durable execution of workflows that temporal promises seems like it was made for us. And once code is “temporalized” we get to eject a bunch of ad-hoc resiliency stuff into the sun, and…
Re: Temporal .NET – Deterministic Workflow Authoring in .NET
#43Re: Temporal .NET – Deterministic Workflow Authoring in .NET
#44I’m confused on something. What’s the difference between Temporal and something like Dagster/Airflow/Prefect? Is there a difference between ETL and workflows? Or is just branding?
One big difference is those three are Python only, and Temporal is Go, Java, JS/TypeScript, Python, PHP, and .NET. Usually another difference between most workflow tooling and Temporal (granted I have not checked with these) is the care they take in handling errors, retry, replay, cancel, etc so that'd be worth checking as well.
Re: Temporal .NET – Deterministic Workflow Authoring in .NET
#45Another library that is doing the same thing: https://github.com/Azure/durabletask
Re: Temporal .NET – Deterministic Workflow Authoring in .NET
#46Earlier quoted context omitted.
Hrmm, I will investigate using an expression tree for this (now's the time while it is alpha). I was hoping to avoid people having to create lambdas. I hope I don't run into overload ambiguity with the existing `ExecuteActivity` calls where you can just pass an existing method as Func param. I will investigate this approach, thanks! Of course the "Ref" pattern is user-choice/suggested-pattern, it's not a requirement…
If it's possible to use both approaches without cluttering your API, that may be the best solution. I know a lot of more junior devs that have a difficult time wrapping their head around expressions in C#. Excellent library!
Re: Temporal .NET – Deterministic Workflow Authoring in .NET
#47For those not familiar with workflows as code, a workflow is a method that is executed in a way that can't fail—each step the program takes is persisted, so that if execution is interrupted (the process crashes or machine loses power), execution will be continued on a new machine, from the same step, with all local/instance variables, threads, and the call stack intact. It also transparently retries network requests…
What's the difference between workflows as code and using an eventbus? Or is the same? With RabbitMQ if a machine dies whilst processing message it will automatically requeue that message such that another consumer can process it.
- Creates and updates events/messages for you
- Maintains consistency between the events and timers and the state of the processing flow. More info on why this is important for correctness/resilience: https://youtu.be/t524U9CixZ0
The difference between workflow code and using an event bus is that with the former, the above is done automatically for you, and in the latter, it's done manually, which can be a lot of code to write and get right, and is harder to track/visualize what happened in production and debug. It would also take a lot of events to get an equivalent degree of reliability—the message processor would need to do a single step and then write the next event to the bus. So a 10-line workflow-as-code function would translate to 10 different events in the bus route.
Also, the event bus route doesn't have the new possibilities I listed in the parent comment.
Re: Temporal .NET – Deterministic Workflow Authoring in .NET
#48I’m confused on something. What’s the difference between Temporal and something like Dagster/Airflow/Prefect? Is there a difference between ETL and workflows? Or is just branding?
Re: Temporal .NET – Deterministic Workflow Authoring in .NET
#49The Typescript SDK is amazing. It strikes a nice balance, being straightforward to use without most of the common pitfalls related to non-determinism, thanks to the Temporal SDK using Node's VM module to execute code with patched sources of non-determinism, like `Date` and `math.random`.
The only caveat is running it (Temporal Server). After mulling it over, for this project I sticked with running everything in a single VPS. If for some reason I get more users one day, maybe consider a Kubernetes managed service. Temporal Cloud is also an option, just not for me at the moment (region constraints, plus it's a pet project so no money)
But the local developer experience is actually amazing. Temporal is a joy all around, to be honest.
Re: Temporal .NET – Deterministic Workflow Authoring in .NET
#50Earlier quoted context omitted.
If it's possible to use both approaches without cluttering your API, that may be the best solution. I know a lot of more junior devs that have a difficult time wrapping their head around expressions in C#. Excellent library!
After looking at it, I am concerned it is not possible for a clean experience. We have to give guidance and samples and we have to choose a way of referencing methods in those. Having ambiguous approaches is a bit rough. We may have to just move to expressions.