Options for calls between functions in different Function Apps

Question

Options for calls between functions in different Function Apps

Andrew Syrov 51

Can anyone point to a reference for different options to call one function from another across different function apps?

All reference architectures that I see fall into the following categories:

#1 Client calls function by HTTP trigger and function returns the result (sort flat architecture with no calls between different function apps).
#2 HTTP trigger creates a durable function which then called some other functions using HTTP (and I guess does some writes to storage, while running).

Yet, if we have different function apps developed by different teams, deployed separately. How do we, in some efficient way call function in a different app (which also can call further app functions). I'm also looking for ways to reduce the number of writes to different storages (queues, etc) during this chain of calls.

The only way I see it, such a chain of calls may be done using HttpClient. Yet, this sounds like there should be a better way (such as azure itself should know how to do cross calls between different Function Apps).

Thanks!

1 answer

Your answer

Answer 1

Pramod Valavala 20,656 Microsoft Employee Moderator

@Andrew Syrov Using HTTP is probably the simplest way to go about this and is widely used for most microservice deployments. Usually, deployments leverage a service discovery component to route requests or use a single API Gateway for all services.

In Azure, you can use Azure APIM to register all functions under the same endpoint. This allows you to send requests to the same endpoint irrespective of which function app they are in. Check this doc that talks about Gateway Aggregation.

But there are scenarios where you could leverage other options like message queues. Use these, you can implement patterns like Choreography.

Finally, Durable Functions are a great option too if you need to run long-running processes without dealing with the underlying queues.

Andrew Syrov 51 Reputation points

2021-07-02T21:43:56.18+00:00

This is a very good explanation.
Thank you very much for spending time on it.

The last question that I have is this: There is a nice way to make synchronous calls (from a client point of view), yet use Service Bus to communicate. Basically, the client calls HTTP Trigger this triggers puts message to queue with ReplyToSessionId and then waits with AcceptMessageSessionAsync(id) and returns a response to the client.

I think this is a very good option. But appears the only messaging service that supports this is ServiceBus. Or are there other Messaging services that support this? (my concern is that ServiceBus may be too heavy for this work)
Pramod Valavala 20,656 Reputation points Microsoft Employee Moderator

2021-07-06T06:45:12.76+00:00

@Andrew Syrov Yes. That would work. And I think Service Bus would be the best fit. You could use Storage Queues but that involve a lot of polling and doesn't have sessions.

Another simpler approach would be to use the WaitForCompletionOrCreateCheckStatusResponseAsync API with Durable Functions, which allows you to make requests synchronous with a fallback to asynchronous if it takes too long. This does use storage queues underneath but abstracts it away.

Share via

Options for calls between functions in different Function Apps

1 answer

Your answer