Azure Static Web Apps

Azure Static Web App (SWA) is a tailored hosting plan for apps with pre-built and pre-rendered static front-ends. It was announced at Build last year and went into general availability this year at Microsoft Build. Let us have a look at what is on offer and how it works.

Azure Static Web Apps

Azure Static Web App is a turnkey service for building and deploying full-stack apps. It is a package that consists of an app, which is your static front-end assets and an optional API, fulfilled using an Azure Function. It is well-suited for apps that do not require server-side rendering. So apps built with JavaScript libraries and frameworks like Angular, Vue, React, static site generators like VuePress, Hugo make really good candidates for Azure Static Web Apps. Modern browsers are very powerful and support WebAssembly making it possible to run .NET on the browser with Blazor WebAssembly(WASM) based apps. Azure SWA caters to Blazor WASM Apps too.

Azure SWA is defined as a complete developer solution all the way from local development to hosting. There is a workflow that is very similar to a developer's daily workflow. In a nutshell, developers can check in code to a repo and that gets deployed with GitHub Actions or DevOps pipelines. 

Picture Courtesy : 

Azure SWA has first-class integrations to GitHub and Azure DevOps. The Azure SWA environment is tied up to and watches a branch, for e.g. the main branch in your repo. The repo consists of both your static code as well as the Azure Function. When code is committed and pushed to main or a pull request is merged to main it triggers the deployment of both the static app as well as the API. To help this a GitHub Action is created in the repo when you create the resource in the Azure Portal. So I, as a developer, can focus on development and the DevOps aspect is taken care of for me. All the tokens are stored as GitHub secrets or in Azure KeyVault which makes all the sensitive information stored securely. 

Developers can also benefit from staging environments for testing. Whenever a pull request is created against the repo branch that your SWA watches, it deploys the change to a staging environment. This mimics the production app and can be used to test your changes. Merging the PR triggers a deployment to the production version of the app. Merging or closing a PR also deletes the staging environment, so the environment kind of maintains itself. It completely on-demand!

Now, you might think that Azure Storage can be used for the same purpose. There are some standout features though

  • Globally distributed static content - The static content is always served from a location close to the user and hence, very performant and always optimised for static content delivery
  • Free SSL certificates
  • Custom domain support
  • Integrated API Support using Azure Functions
  • Integrated Authentication provider support and customisable authorisation rules

There are 2 hosting options - Free Plan (for personal/hobby projects) and Production Plan(for production apps). All of the above are available with both plans. But the major difference between the two plans is in the app size, API Support and the number of staging environments. The Production plan benefits from 500MB app size and 10 staging environments at any time compared to 250MB and 3 staging environments on the Free plan. The free plan only offers the Managed API support, where the API is part of the same package. With the Production plan, you can bring in your own Azure function which gives more flexibility. A full comparison between the two plans can be found here


REST : Myths & Facts

01 December 2023

This article discusses some of the misconceptions about REST, and what is not REST and presents you with the facts.