DEV Community

Discussion on: Stateful Serverless with Durable Functions

Collapse
 
aaronpowell profile image
Aaron Powell

It's true that Durable Functions, like AWS Step Functions, aren't going to be suitable for every scenario as they do create an explicit relationship between the functions used.

Some scenarios that they are valid for are things like sequential processing, waiting for human interaction or monitoring another system.

Behind the scenes Durable Functions is using the approach you describe, using messages to do communication between the functions (using a combination of queues and table storage (in v2 the storage model is abstracted so you can swap that out)).

Now, it may seem like we're doing explicit linking of functions in the way they are called:

[<FunctionName("StartWorkflow")>]
let startWorkflow
    ([<HttpTrigger(AuthorizationLevel.Anonymous, "get", Route = "start/{input}")>] req : HttpRequest)
    ([<OrchestrationClient>] starter : DurableOrchestrationClient)
    input
    (logger : ILogger) =
    task {
        logger.LogInformation(sprintf "Starting a new workflow for %s" input)

        let! _ = starter.StartNewAsync(eventName, input)

        return OkResult()
    }
Enter fullscreen mode Exit fullscreen mode

(snippet from my sample on GitHub)

But when we do starter.StartNewAsync(eventName, input) we are essentially dropping a message into a queue to be picked up by whomever is meant to listen to eventName.

This becomes even more powerful when we start looking at Entity Functions and start taking a more Actor-model approach to our architecture.