The design of Azure Function Proxy

Question

Hi, we're using function app proxy as middle man between Azure APIM and Logic App (connect to Salesforce).
The structure is like following.

Now a design problem bothers us when trying migration.

We haven't automate deployment process for Azure, everything for now is manual work ((Export Template ->Deploy) . And the original deployment idea is migrating Azure services from STG subscription resource group to PROD resource group.

When we start to deploy , we realize function app cannot follow our idea because it should have unique name over resource groups. That makes us wonder if it's necessary to separate STG and PROD function proxy.

If we keep single function proxy, just using different route template to identify STG/PROD backend, like following concept. Is this good ? keeping single App Service plan might reduce the cost as well ? or any side-effect in the future ?

Need your advice, much appreciated!

Answer 1

@Amy Z Having separate resources for staging and production is indeed the way to go and having separate function app names shouldn't be a problem since the deployment could configure APIM as well with the different URLs.

In fact, you could just have the Logic Apps directly configured to APIM to keep things simple since the function app isn't doing much. When deploying the ARM Templates, you can get the trigger URL dynamically and update the backend sub-resource of APIM. This SO post highlights how you can fetch the trigger URL for a Logic App.