This is an addon nuget package, though, and not something that comes out of the box (unless I can convince the team to include it in the template). I've been working on a Roslyn Analyzer which will detect incorrect names, wrong parameters and broken return types. There are a few hacks you can use like leaning on nameof but they're not satisfactory. This is a limitation I've called out on twitter and in my durable functions talks. This requires the use of "magic strings" for the function names, definitely not refactoring-friendly. Speaking of calling other functions, to do that you use the DurableOrchestrationContext's CallActivityAsync("FunctionName"). The dangers of an all-encompassing durable function could be mitigated somewhat by doing all the real work in normal azure functions which are called from the orchestrator, and having the durable function be very lightweight, but this is a bit of a slippery slope. It is completely isolated in its own vertical slice, and can communicate with other vertical slices in a lightly-coupled manner by publishing events.
Nservicebus vs masstransit series#
This provides the logical separation similar to what you'd get with a series of sagas in NSB.Ī Saga on the other hand is a kind of "policy" object which statefully handles a few interrelated messages.
Probably a better approach is to have a Durable Function simply drop messages on a queue which will trigger other functions which may or may not be durable. This seems like another place where sub-orchestrations could come into play. This is both a strength (easily seeing the big picture) and a weakness (lots of coupling, can grow very complex).Īdditionally, if you're trying to divide your system along service boundary lines (the vertical slices with independent databases mentioned in article) a giant orchestrator function covering an entire process flowchart makes this really difficult. On the other hand, with a durable function, it's easy to have an entire process represented as one durable orchestrator function that can call other functions. When thinking about a large process flowchart, one Saga will typically govern just the interactions at one point on the flowchart, not the entire process. will get you into trouble! ()Ī Saga will typically focus on the interaction of one or two messages at a time. DateTime.Now, random numbers, Guids, etc. So with durable functions you need to be careful that your orchestrator's implementation is deterministic. There is no nice way to find the running function like NSB does with Saga finding. You have to define a message handler and then raise the event. You can trigger durable function continuations using external events but the mechanism is certainly less seamless than with NSB. That means continuation of the durable function is driven by awaits, not by additional messages.
One big difference is that a durable function is a non-message-bound orchestrator for other functions or processes.
After all, an NServiceBus saga is essentially an NServiceBus message handler with durable state, and a durable function is an Azure Function with durable state. There's definitely some similarities between durable functions and sagas. Our position is guaranteed to evolve over time. This is just a few engineers throwing thoughts against the wall. Before continuing, a quick disclaimer: Durable Functions are extremely new.
0 kommentar(er)
