Integrated API Support in Azure Static Web Apps

28 August 2023

In this article, we will look into the Integrated API Support provided by Azure Static Web Apps(SWA), with a focus on Azure Functions. 

One of the key features of Azure SWA is the integrated API support that it provides. With the integrated API support you get

  • Seamless routing, with the /api path available to the app without any CORS rules, made possible via a reverse proxy
  • Integrated security, whereby the role-based user authentication and authorization data are available to the API as special headers

There are two different API integration options with Azure SWA

  • Managed APIs
  • Bring Your Own APIs

Managed APIs

This is the default set-up for Azure Static Web Apps and the only API integration option available in the free plan for Azure SWA.

Managed APIs make use of an Azure Function as the API backend. With Managed APIs, this integration with Azure Function is automatically achieved by the SWA platform and Azure Functions is the only available choice as the backend API. With this option, the static app and the API are part of the same SWA resource and are managed and deployed as a single resource. The API is managed completely by the SWA resource and a deployment to the SWA would mean a deployment to both the app as well as the API. The Azure function which forms the API is available to use only within the SWA resource and not outside the environment. The Azure Functions only supports a limited set of Azure Functions runtimes and is based on the Consumption plan only. There is a single function app in this integration option but you can have multiple functions. Application Insights on the Azure SWA provides logging support.

Bring Your Own API

The Bring Your Own API is available for Azure SWA Standard(production hosting) plans alone. With this integration option, you can “link” your Azure SWA to an existing Azure Function, Azure App Service, Azure Container App or Azure API Management. With this integration option, your app and API are managed as separate resources. Deployments to the app and API are separate too as the deployment to Azure SWA only deploys the app. This means you are responsible for the deployment workflow of your API. The “api_location” field in the GitHub actions file must be set to an empty string in this case.

Bring Your Own Azure Function

When using your own function as the backend API, all available Azure Functions runtimes are supported. For this, an apiRuntime property can be added to your SWA configuration file. Your Azure Function can be on a Consumption, Dedicated or Premium plan. In addition to this, you can bring in Durable functions as your API and use Key Vault references for secret storage. Most importantly your Azure Functions is available outside the SWA environment, unlike the Managed API. Application Insights can be used on your Azure Functions to enable logging.

Bringing your own Azure Function also means that the function url must have a /api prefix. When your Azure SWA is linked to your Azure Function, any requests to /api is sent to your Azure Function from the same domain as your Azure SWA thereby respecting the seamless routing for your API.

For example if you have an Azure SWA at https://my-azureswa.azurestaticapps.net that is linked to a function at https://my-own-function.azurewebsites.net/api/sayhello, the api calls from the app will be made from the same domain as the Azure SWA https://my-azureswa.azurestaticapps.net/api/sayhello

To see a working example look at my demo site. The app uses a Bring Your Own Azure function but the requests from my app to the API are made from the same domain as my Azure SWA.

When an Azure SWA is linked to your Azure Function, it creates an identity provider for the Azure SWA. To make your Azure Function available outside the SWA, to other applications, you must explicitly set up another identity provider or allow unauthenticated access.

If your Azure Function has a function key, it must be passed with requests from the app.

Your Azure Function may respond to various triggers but the app can only work with HTTP trigger

API Gotchas

There are certain constraints that you have to be aware of as well when it comes to API support with Azure SWA

  • The free hosting plan of Azure SWA only supports Managed APIs
  • A SWA environment can only be linked to one type of backend API
  • Route prefix is /api and it cannot be changed
  • Only HTTP requests are supported, and no WebSocket connections
  • Routing rules only support redirects and securing routes