Making a Static Website with C#, Blazor, AWS And GitHub Actions

Blazor lets you build interactive web UIs using C# instead of JavaScript. Blazor apps are composed of reusable web UI components implemented using C#, HTML, and CSS. Both client and server code is written in C#, allowing you to share code and libraries.

Setting up the project

• .NET Core (you’ll need ≥ v3.1.0)
• and Visual Studio

Develop your site

• Pages (aka Razor pages — using the 

  .razor

   file extension) — these define the route and layout of a given page in the UI. These pages can contain HTML elements and C# code. In the following example, you can see the C# code defined using the 

  @code

   block:

@page "/counter"

<h1>Counter</h1>

<p>Current count: @currentCount</p>

<button class="btn btn-primary" @onclick="IncrementCount">Click me</button>

@code {
    private int currentCount = 0;

    private void IncrementCount()
    {
        currentCount++;
    }
}

• Components — these are used to encapsulate some piece of UI and it’s functionality. These generally take shape as some sort of reusable form or control. Using Components can be a great way to add extensibility and create a simple, clean application. A Component is defined in a .razor file, and can optionally have a corresponding .cs file to contain the C# code. Below is an example of a component I created to contain a simple page header for my website:

@namespace Tayco.Web.Components
@inherits PageHeaderBase

<MatH2>@Title</MatH2>

<MatDivider />
<br />

using Microsoft.AspNetCore.Components;

namespace Tayco.Web.Components
{
    public class PageHeaderBase : ComponentBase
    {
        [Parameter]
        public string Title { get; set; }
    }
}

Pages\Counter.razor

Pages\FetchData.razor

Further considerations

• Since there is no server hosting your .NET code in the Blazor WebAssembly hosting model, your browser needs to download the necessary DLLs to run the code. This results in a relatively large payload to load the site (my small site comes to just under 6MB). It also means that the DLLs are accessible to anyone who accesses your site. If either of these are a concern for you, you may want to consider the Blazor Server hosting model.
• There are already a ton of third-party libraries that you can use to simplify/extend your Blazor app. Id suggest taking a look at the Awesome Blazor GitHub repo which contains a growing list of resources. I ended up using the MatBlazor library, which provides a ton of easy-to-use Material Design components.
• I lightly grazed over the actual functionality in Blazor in this post. There is a lot more available, so I’d strongly recommend taking a look at the docs to learn more of what’s offered.

Hosting in AWS

• Simple Storage Service (aka S3) - As the name suggests, this is where the files for our website will be stored
• Route 53 - This allows us to associate a public domain name with our content in S3
• CloudFront - This one is optional. It simply provides better performance when loading our website by caching data in locations closer to end-users

Pricing

Publishing the Blazor app

• Visual Studio - When presented with the option to pick a publish target, choose "Folder"
• dotnet command line - Here is the command that I ran to publish my app: 

  dotnet publish -c Release -o publish Tayco.sln

  . I'd recommend getting familiarized with the CLI if you're not already. We'll be using this in a later post in setting up a Continuous Deployment pipeline.

index.html

wwwroot

CI/CD with GitHub Actions

1. Build our Blazor app
2. Grab the distributable contents
3. Copy them to our S3 bucket in AWS

1. Frequency of changes
2. Number of contributors

Building Workflows

1. I already had my source code in a GitHub repository. 
2. There is a free tier available that meets my needs (see additional pricing options).
3. I found the documentation thorough and easy to navigate.
4. There's a marketplace where Actions can be created and shared by the community.

/.github/workflows

name: Upload Website

on:
  workflow_dispatch:
    inputs:
      input_name:
        required: false
        default: "Upload Website - Manual Trigger"
  push:
    branches:
      - master
    paths:
      - 'src/**'

jobs:
  build:
    runs-on: windows-latest
    steps:
      - uses: actions/checkout@master
      - uses: actions/setup-dotnet@v1
        with:
          dotnet-version: '3.1.300'
      - run: dotnet build -c Release
      - run: dotnet test -c Release --no-build
      - run: dotnet publish -c Release --no-build -o publish Tayco.sln
      - uses: actions/upload-artifact@v1
        with:
          name: dist
          path: publish/wwwroot
  deploy:
    needs: [build]
    runs-on: ubuntu-latest
    steps:
      - uses: actions/download-artifact@v1
        with:
          name: dist
      - uses: jakejarvis/s3-sync-action@master
        with:
          args: --acl public-read --follow-symlinks --delete
        env:
          AWS_S3_BUCKET: ${{ secrets.AWS_S3_BUCKET }}
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          SOURCE_DIR: 'dist/'

on

on:
  workflow_dispatch:
    inputs:
      input_name:
        required: false
        default: "Upload Website - Manual Trigger"
  push:
    branches:
      - master
    paths:
      - 'src/**'

on

1. workflow_dispatch

   - This is a recent addition that allows the workflow to be manually queued through the UI. Prior to this you would have to trigger a different event (e.g. push a commit) in order to run the workflow.

2. push

   - As you might guess, this event is any push to the repository given a set of conditions. Our conditions are any push to the 

   master

    branch with changes in the 

   src/

    directory.

jobs

jobs

1. runs-on: The environment that the job will run in.
2. steps: These are the tasks that will be run within the job.

build 

deploy

build

build:
    runs-on: windows-latest
    steps:
      - uses: actions/checkout@master
      - uses: actions/setup-dotnet@v1
        with:
          dotnet-version: '3.1.300'
      - run: dotnet build -c Release
      - run: dotnet test -c Release --no-build
      - run: dotnet publish -c Release --no-build -o publish Tayco.sln
      - uses: actions/upload-artifact@v1
        with:
          name: dist
          path: publish/wwwroot

1. Checkout the latest version of the 

   master

    branch. (Remember that this job runs after any push to 

   master

    in the 

   src/

    directory.)
2. Setup 

   dotnet

   . This a community Action that can be found in the marketplace (see here).
3. Build using the Release configuration.
4. Run our tests.
5. Publish our contents explicitly into a 

   publish

    directory.
6. Upload the publish artifacts (using this Action) - This step is important because it allows us to reuse artifacts between jobs, as we'll see next.

deploy

deploy:
    needs: [build]
    runs-on: ubuntu-latest
    steps:
      - uses: actions/download-artifact@v1
        with:
          name: dist
      - uses: jakejarvis/s3-sync-action@master
        with:
          args: --acl public-read --follow-symlinks --delete
        env:
          AWS_S3_BUCKET: ${{ secrets.AWS_S3_BUCKET }}
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          SOURCE_DIR: 'dist/'

needs: [build]

build

1. Download the 

   publish

    artifact that we uploaded in the 

   build

    job.
2. Upload the artifacts to our S3 bucket using the S3 Sync community action.

deploy

${{ secrets.<SECRET_NAME> }}

Automate all the things

1. PR Build: This runs against any Pull Request submitted against the 

   master

    branch. It just builds and runs the tests for the changes, ensuring that things are mostly working before merging into 

   master

    (which will then trigger the Upload Website workflow).
2. Upload Blogs: As the name implies, this workflow runs when a change is made to the 

   /blogs/

    directory on the 

   master

    branch. It simply copies the contents into the S3 bucket that I use to serve the actual blog content to the application at runtime.

Summary