Part 1: Hosting Blazor WebAssembly App on Azure Storage Static Website with Azure CDN defined in Bicep
Blazor WebAssembly or Blazor WASM is a newer form of client side execution (compared to Single Page Applications or SPA) running on your browser which contains a proper .NET runtime implemented in WebAssembly, a standardized bytecode for the web and is supported by modern browsers. It is in it’s own class of of web application known as Progressive Web Application (PWA). This makes it as an interesting option to leverage for client side development as well as for hosting because just like SPA, contents are downloaded to the client side for execution. Note that there is also a different flavor of Blazor which is server side so as not to be confused. Next up, let’s take a look at how we can host a Blazor WASM App with Azure Storage.
Azure Storage has the ability to host a static website and this feature has been available for a while now. This is prefect for hosting my Blazor WASM App as a cost effective option because A, storage is cheap and B, the other part of the cost is egress charges which will be minimal. I also plan to include Azure CDN as part of my solution to further drive down the cost. My other reason for using Azure CDN is because I can have the option of adding my custom domain name on top of Azure CDN and not expose my Storage Account.
Part 1 of this two part series is going to be focused on defining the resources to create on our Azure environment which includes our Storage Account and CDN. Part 2 will be focused on building the Azure environment and deploying our Blazor WASM App to the Storage Account using GitHub Action.
To create my resources and I plan to use bicep. For those who are new to bicep, bicep brings a powerful way to create Azure resources. Compared to ARM Template which is JSON based, this is a new language that enables us to have typed-safe way to express our Azure resources and without the baggage of the JSON structure. Everything we write is strictly related to the Azure resource we are creating.
To follow along, I highly recommend using Visual Code with the Bicep VS code extension.
To begin, let’s create a file with a good name followed by .bicep. First, we define our storage account.
The bicep syntax here represents a way to define an Azure resource. There are 2 variables, which are webStorageAccountName and location. The next step is to enable static website on the Storage Account. There is no ARM Template way of enabling a static website and it must be done using Azure PowerShell or Azure CLI script. Here, we make use of a fairly new capability to run scripts in our ARM template using Deployment scripts.
There are two key aspects to take note of when using deployment scripts. First, the user identity is used. The user identity is a managed user identity created for the purpose of running a script. The managed user identity must be assigned an appropriate role in the same resource group. Refer to this link for more information on the exact permissions.
The name of the managed identity is used in the managedUserId parameter as seen in the script on line 12.
We will also notice that we are using a bicep function called the loadTextContent to load Powershell script commands in instead of having to write our Powershell script directly inside this biecep file. This is a great new feature! The following is part of the Powershell script to enable the static website via the Enable-AzStorageStaticWebsite command.
Here, we should also take note of two parameters. The IndexDocument and ErrorDocument404Path. The IndexDocument defines the which page is loaded and by default, the Blazor WASM will have an initial index.html page where it defines all the HTML, Javascript, CSS to be loaded. The reason why ErrorDocument404Path is set to index.html is because in cases where the user is doing a refresh on a particular route on the Blazor WASM App, there’s no page to “process” that. Hence, it is set to index.html so that the Blazor WASM App can process that route.
Notice that we are adding an output for the storage account web endpoint. This would be used later for setting up the CDN endpoint. First, let’s setup the CDN resource.
Now, we are ready to setup the CDN endpoint. Notice that we are using the output here to define the origin which is the Storage Account Static website Url.
We can close off by defining the input parameters in our bicep file. The solution can be found on my github repository here: https://github.com/seekdavidlee/az-blazor-wasm-storage-static-website.
In the next article, we will talk about creating a GitHub Action Workflow to build our Blazor WASM App and deploy into our Azure environment. Stay tuned!
