re: Stateful Serverless with Durable Functions VIEW POST

FULL DISCUSSION
 

Hi, interesting topic.

Many would argue that wiring functions directly is an anti pattern. Makes it difficult to introduce changes down the road, for example.approach

Alternatives could be any indirect way of calling functions internally: a msg-driven approach, an API gateway or application balancer in front of functions...

What's your view on that architectural topic and how useful durable functions can be if in an indirect call approach?

 

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()
    }

(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.

code of conduct - report abuse