> TLDR; Azure Static Web Apps is a service that allows you to deploy both JavaScript apps but now also Blazor apps. The service is simple to use as it only requires an Azure subscription and a GitHub repo. That's all the set up you need.
Blazor is a framework that allows you to write C# fullstack. If you are developing a fullstack web application, you usually have to involve JavaScript at some point. You either add it to improve the interaction of your pages or you split between having a backend in .NET and the frontend in JavaScript using for example a SPA framework like React, Angular or maybe Vue. A Blazor app can be compiled into WebAssembly and can thereby be a first-class web citizen and also really fast.
If you are completely new to Blazor I recommend reading this intro article.
Static Web Apps is an Azure service with which you can deploy fullstack apps within minutes. It can deploy both JavaScript projects as well as Blazor.
NET developer here, you have my attention. So, it can deploy a Blazor project, what else can it do?
That's a nice featurelist. I care about ease of use, what can you tell me about that?
There's not much to fill in, everything revolves around your GitHub repo and once you selected a repo, and a few other things, it starts deploying it.
Ok, but how does it work under the hood?
It works by creating and running GitHub actions that carries out things like fetching dependent libraries, building your code, and finally deploying it. You end up getting a so-called workflow file pushed to your repo (it's a YAML file).
Alright, but I'm likely to update my code quite a lot, does it help me with redeploy?
It does, you can define in the workflow file when a redeploy should be trigger, like merging of a PR or a commit to master/main branch for example.
This all sounds very promising; can you take me through a deploy?
Of course, next thing on my list :)
git clone <name of repo URL>
dotnet build
cd Client
dotnet run
You should get a terminal output similar to the following:
info: Microsoft.Hosting.Lifetime[0]
Now listening on: https://localhost:5001
info: Microsoft.Hosting.Lifetime[0]
Now listening on: http://localhost:5000
info: Microsoft.Hosting.Lifetime[0]
Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
Hosting environment: Development
info: Microsoft.Hosting.Lifetime[0]
Content root path:
/path/to/project/blazor-sample/Client
At this point you have a working Blazor app that you can deploy using Azure Static functions. How do you do that?
Now you are met with a set of dropdowns where you need to fill in some info.
Click to be taken to the resource once deployed. The resource page should look something like this:
Above you have the resource. You could click the URL from the indicated field, but it would take you to default page. Why is that? Your app hasn't finished building yet. Instead click the link GitHub action runs. This will take you to the GitHub actions of your repo. Once all the actions have finished it should look like so:
Now a Blazor app could contain its own backend. The way the Azure Static Web Apps service is constructed though it assumes your backend will be located in an Api directory. So what should be in that directory? Well a function app. Luckily your repo already have a working function app, almost.
Let's review our repo quickly. Your solution should look something like this.
-| Api
-| Data
-| Client
You already know about the Client directory where your Blazor app lives. The other directory of interest is the Api directory that contains a Function app. It's an almost functioning Function app. What do I mean by almost? Well let's have a look at it, expanding the Api directory there are some files of interest:
Client/
Api/
ProductData.cs
ProductsDelete.cs
ProductsPost.cs
ProductsPut.cs
The first file ProductData.cs
contains an in-memory data store. The remaining three files is just routes for our API.
For this API to be a full Create Read Update Delete it needs another file ProductsGet.cs
, let's create that file and give it the following content:
using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.AspNetCore.Http;
namespace Api
{
public class ProductsGet
{
private readonly IProductData productData;
public ProductsGet(IProductData productData)
{
this.productData = productData;
}
[FunctionName("ProductsGet")]
public async Task<IActionResult> Run(
[HttpTrigger(AuthorizationLevel.Anonymous, "get", Route = "products")] HttpRequest req)
{
var products = await productData.GetProducts();
return new OkObjectResult(products);
}
}
}
Now select Run > Start debugging from the top menu in VS Code. At the end of the build output you should have text stating something like this:
ProductsPut: [PUT] http://localhost:7071/api/products
ProductsGet: [GET] http://localhost:7071/api/products
ProductsPost: [POST] http://localhost:7071/api/products
ProductsDelete: [DELETE] http://localhost:7071/api/products/{productId:int}
You are almost there.
When testing things out locally you need to instruct the Function to allow requests from a cross domain, i.e our Blazor app. How do we do that? Locate the local.settings.json file and ensure it has the following content:
{
"IsEncrypted": false,
"Values": {
"AzureWebJobsStorage": "",
"FUNCTIONS_WORKER_RUNTIME": "dotnet"
},
"Host": {
"CORS": "*"
}
}
Above you added the Host property and made CORS point to allowing all requests. This is just something we do locally, don't worry about this making production.
At this point you can run your client Blazor app and it will look like this:
The Blazor app is now able to talk to your Function app backend.
So how do you deploy this so that the API part is there? You need to do the following:
That's it, the way the workflow file is constructed it should pick up the changes on push and redeploy the app.
Open up the workflow file. It's a file ending in .yml in your .github sub directory (ensure you have done a git pull before this so you get this file as it's created and added to your repo the first time you deploy).
Locate the section called api_location:
. Ensure it looks like this api_location: "/Api". This will point out our Api sub directory.
Type the following command:
git add .
git commit -m "adding API"
git push
The above should push your changes to GitHub and the GitHub actions should be triggered.
You should now see the deployed app, this time loading the data correctly
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.