Azure Static Web Apps can deploy static content and serverless APIs from a GitHub or Azure DevOps repository, acting as a single, globally distributed service.
Let’s see it in action. Imagine you have a simple React app and an Azure Functions API.
Project Structure:
my-static-app/
├── api/
│ ├── GetGreeting.cs
│ └── function.proj
├── src/
│ ├── App.js
│ ├── index.js
│ └── index.html
└── azure.config.json
src/index.html:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>My Static App</title>
</head>
<body>
<div id="root"></div>
<script src="index.js"></script>
</body>
</html>
src/App.js:
import React, { useState, useEffect } from 'react';
function App() {
const [greeting, setGreeting] = useState('');
useEffect(() => {
fetch('/api/GetGreeting')
.then(response => response.json())
.then(data => setGreeting(data.message));
}, []);
return (
<div>
<h1>Hello from Static Web App!</h1>
<p>{greeting}</p>
</div>
);
}
export default App;
api/GetGreeting.cs:
using System.IO;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.Logging;
using Newtonsoft.Json;
namespace MyStaticApp.Api
{
public static class GetGreeting
{
[FunctionName("GetGreeting")]
public static IActionResult Run(
[HttpTrigger(AuthorizationLevel.Anonymous, "get", "post", Route = null)] HttpRequest req,
ILogger log)
{
log.LogInformation("C# HTTP trigger function processed a request.");
var responseMessage = new { message = "Greetings from the API!" };
return new OkObjectResult(responseMessage);
}
}
}
azure.config.json:
{
"app_location": "src",
"api_location": "api",
"output_location": "build"
}
When you push this to a GitHub repository, Azure Static Web Apps automatically detects the azure.config.json file. It then builds your frontend application (e.g., using npm run build for React) and deploys the static assets to a global CDN. Simultaneously, it deploys your Azure Functions API to a serverless environment. The service automatically configures routing so that requests to /api/* are handled by the Functions runtime, while all other requests serve your static content.
The core problem Azure Static Web Apps solves is the complexity of hosting and scaling both static frontend assets and dynamic APIs. Traditionally, you’d need separate hosting for your frontend (e.g., Azure Blob Storage with CDN) and your backend (e.g., Azure Functions App or App Service). This involves managing separate deployment pipelines, configurations, and scaling strategies. Static Web Apps unifies this into a single, managed service.
Internally, the service leverages Azure CDN for global distribution of your static files. For the API, it provisions and manages an Azure Functions environment. The "magic" happens in the routing layer, which is a managed component that directs traffic appropriately. You control the frontend build process via app_location and output_location, and the API’s runtime and dependencies via api_location and standard Azure Functions configuration files.
The most surprising thing is how seamlessly it integrates with CI/CD. By default, it sets up a GitHub Actions workflow (or Azure DevOps pipeline) that triggers on every push to your main branch. This workflow automatically builds your frontend, deploys the static assets, and deploys your API functions. You get a fully functional, globally distributed web application with a live API endpoint, all from a single git push.
You can configure custom domains, authentication providers (like Azure AD, GitHub, Twitter), and environment variables directly through the Azure portal or ARM templates, abstracting away much of the underlying infrastructure management.
The next hurdle is understanding how to manage API authentication and authorization within this integrated model.