Azure Static Web Apps: a first look

Although the two have a lot in common, even including parts of the name, there are a few very clear differences between Static website hosting in Azure Storage and Static Web Apps. We’ll have a look at what those differences are and take a first look at the most recent of the two: Static Web Apps.

Static website hosting in Azure Storage

Static website hosting is a feature you can enable free of charge on a storage account. This feature is available on general-purpose v2 Standard storage accounts and not in any other types. Enabling the feature creates a $web container where you can host your static files. It’s even possible to setup a custom domain for the static website.

For a step-by-step guide see the Host a static website in Azure Storage article.

Static Website hosting also has some limitation which are listed below.

• CORS is not supported
• No support for HTTPS with custom domains
• Unable to configure headers

The second and third are relatively easy to solve by adding Azure CDN.

The static website can, of course, connect to an external API like for example an ASP.NET Web API or HTTP triggered Azure Functions. It doesn’t do anything for that, it just enables you to call them. If you’re the one developing this API, you’re responsible for deploying and hosting that API. That’s where Static Web Apps come in …

Static Web Apps

A modern web app service that offers streamlined full-stack development from source code to global high availability.

Static Web Apps seems more like a combination of several services bound together in an Azure-branded offering. It combines the power of source code control from GitHub, CI/CD with GitHub actions, something that acts a lot like static website hosting and the awesomeness of Azure Functions. Together, they automatically build and deploy full stack web apps, consisting from to Azure from a GitHub repository.

So… what does it do?

The workflow of Azure Static Web Apps is tailored to a developer’s daily workflow. Apps are built and deployed based off GitHub interactions.

When creating an Azure Static Web Apps resource, there’s a GitHub Actions workflow created in the repo you specify upon creation. This workflow automatically builds and deploys your app, and its API if you specified it, to Azure on each push to (or PR that is accepted into) the branch you specified.

Static assets are hosted in Azure and will be served from points physically close to the users. The accompanying API endpoints are hosted using Azure Functions which eliminates the need for a back-end server completely.

Creating an Azure Static Web App

When creating a Static Web App, the Azure portal asks you to specify a couple of things. Most importantly, you need to sign in with GitHub and pick the repo and branch you would like it to keep an eye on. This is the repo the GitHub Actions workflow is created in, and the branch that triggers it.

Next up: specifying where to find what to build and where the output goes. As you can see in the screenshot below, the first input needed is ‘App location’. This is the folder where the frontend you want to build can be found in the repo. It defaults to the root (/).
The second input, ‘API location’, is optional. It holds the location of the API that goes with your frontend. If you don’t want to specify it now, that’s not an issue. However, you do need some GotHub Action / YAML knowledge if you want to add it later.
The final input asks for the artifact location. This is the location of the build output relevant to the App location. So if youset App location to be ‘/src’ and Artifact location to be ‘public’, the content at ‘/src/public’ will be pushed to the static web app.

After you’ve created the static web app, you would expect the app to be available at something like staticwebappname.azurestaticapps.net. Or at least I expected this. This is not the case, however. A globally unique name is generated for you and used in the URL. The static web app I created when I took the screenshots got the name mango-smoke-022564a03.

Management from the Azure portal

The Azure portal doesn’t provide a lot of options to manage the static web apps. Most of what you configured when creating it ended up in the GitHub Actions workflow. They do, however, link to connected resources in GitHub. Like for instance recent runs, the workflow file and the repo the static web app is connected to.

The portal does enable you to add some environment specific (more info on this later) configuration settings, add custom domains and look at the Functions that are connected to the static web app. You do not have any say in how those Functions are hosted, by the way. Currently only JavaScript Functions are supported. Since TypeScript Functions are transpiled into JavaScript you can use that as well.

And then there’s the ‘Environments’ menu item. This is maybe one of the most powerfull features of Static Web Apps, since …

Staging environments are automatically created when a pull request is generated, and are promoted into production once the pull request is merged.

That’s kind of a BIG DEAL. I tested it out by creating a separate branch on my GitHub repo, completely changing the design of the website and creating a PR. And it worked. It created a separate environment that showed me the result of what the website would look like if the Pull Request were to be merged.

There’s Access control (IAM) like on other Azure resources. Role management, Locks and the possibility to export a template complete the Blades for static web apps. For now.

Finishing up

If you got all the input correct on the first attempt, you’re probably good to go. When I created my first static web app a while back I started with an Angular frontend and later on added the API. I had to change some stuff in the workflow file and search around a bit to make sure I had everything in place.

If you’re interested in the entire workflow file, have a look at the aswa-example repository, but I’ll add the most important part here:

###### Repository/Build Configurations - These values can be configured to match your app requirements. ######
# For more information regarding Static Web App workflow configurations, please visit: https://aka.ms/swaworkflowconfig 
app_location: 'aswa-frontend' # App source code path
api_location: 'aswa-api' # Api source code path - optional
app_artifact_location: 'dist/aswa-frontend' # Built app content directory - optional
app_build_command: 'npm run build-prod' 
###### End of Repository/Build Configurations ######

The app_build_command defines a custom command to build your frontend. By default, it tries to run the npm run build or npm run build:Azure commands. Because my frontend was an Angular app, and the documentation on Custom build commands has an example that you can run ng build --prod to build an Angular app, I thought I was good to go. Unfortunately (and of course) the Angular CLI is not installed globally, which is needed to call it to build an Angular app. That’s why I now have a Pull Request open to change the example in the documentation. 😁

Conclusion

Static Web Apps are a first (?) but very powerful step into bringing Azure and GitHub closer together. Or better yet: to having seamless integration between the two. But as an Azure service, it feels a bit like the odd man out.

The most important reason for me to feel that way is the fact you (currently) have no control over what’s happening in your Azure environment once you’ve created the static web apps resource. All the settings you did while creating the resource landed in the GitHub action and are not editable from the Azure portal anymore. Currently, static web apps are in preview. So this may change. But since that would mean parsing a YAML file that might have been changed entirely from the GitHub side, I think this is unlikely. But I’d love to be proven wrong there. 🤓

Resources

The example I created can be found at aswa.rickvandenbosch.net, the sourcecode is available in my aswa-example repository on GitHub.

Got a question? Contact me!

• azure
• Angular
• Functions
• Serverless
• Typescript
• staticwebapps