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 : https://techcommunity.microsoft.com/t5/apps-on-azure/introducing-app-service-static-web-apps/ba-p/1394451 

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. 

Tools

• Azure Static Web Apps VS Code Extension (Preview) - Create SWA and deploy the resource and code from Visual Studio Code
• Azure Static Web Apps CLI- Emulate the environment locally for testing the app, API, routing rules and authentication
• GitHub Starter Templates - GitHub template repositories for all major frameworks and libraries