Azure Static Web Apps: General Availability May 12 2021


Azure Static Web Apps can now be deployed to Azure in production ready mode as Az SWA have gone GA. There is still a Free plan but now there is the Standard pan which includes such things as BYO Functions, and SLA as well as other new options and increased limits.

Announcement

12 May 2021: Develop production scale modern web apps quickly with Azure Static Web Apps

What are Azure Static Web Apps - from a .NET Developer Perspective

Previously in delivering web content as a .NET Core developer, one option was to create a Blazor app. You had the option of creating a Blazor Server only app or a Blazor WebAssembly (WASM) app. With the former, the web content was rendered by the server using data generated by services on the server. The web content was then sent over Http to the client browser display-ready. With the WebAssembly option, the client requested the data from the server via Controllers on the server, which called services there to generate the data. It was then serialised into text in Json format and returned to the client over Http. The client then rendered the data after deserializing it. For development, with the WebAssembly app, you have two projects; the Server and the Client. With the Server app, you only have the Server project. There may also be a third/second respectively shared project that specifies the data classes. In both cases you only run the Server app. For the WebAssembly, the server delivers the client app to the client browser where it runs. There is a PWA (Progressive Web App) option for teh WASM app to keep that app on the client in which case after installation, the app can be run directly without first running the browser. In developing using Visual Studio, you can deploy the apps directly by publishing the server app, in both cases.

With Azure Static Web Apps there are two (or three) projects. You create a Client app and an API app. As a .NET developer, the Client is again a Blazor WASM app, although there are many other web content rendering alternatives. Again as .NET developer, the API project is a C# Azure Function project containing one or a number of Http Trigger functions, such as for Htpp GET, POST, Put and DELETE. In development mode using Visual Studio, you run both apps locally. You publish the app indirectly via GitHub (and now with GA via Azure Devops) by committing the projects to teh repository. You must first create the repository, up perhaps do one or more initial commits and then create the Azure Static Web App in the Azure Portal. See Tutorial: Building a static web app with Blazor in Azure Static Web Apps from Create a static web app. This step will link back into the repository such that for subsequent commits, GitHub Actions will build and deploy the app to Azure. That tutorial clones the WeatherForecast repository from GitHub with functionality the same a previous .NET Core and Blazor samples. A more detailed tutorial and sample, as discussed in previous blog posts here, is Publish a Blazor WebAssembly app and .NET API with Azure Static Web Apps. Another getting started article using VS Code is Azure Static Web Apps for Visual Studio Code).

About Azure Static Web Apps

  • Globally distributed hosting
    • Can be hosted in Azure around teh world
  • Severless APIs
    • Create an API project with Azure functions
      • Currently as HTTPTriggers, only
    • Create a Client web front end that calls the functions
      • Calls over HTTP (GET,POST,PUT and DELETE) = CI/CD integration
  • Custom Domains + Free SSLs
    • When Az Static Web app is created get a semi-random URL
    • Create a CNAME entry for your domain using Code that the Azure portal provides for that URL from Custom Dommain tab
    • Custom domain is then available via SSL
    • Set up a custom domain + SSL
  • VS Code and local CLI
    • VS Code Extension search for Azure Static Web Apps in VS Code Extensions
    • Local CLI: Can run the whole stack locally: i.e. The API can be debugged locally.
      • Can start both the API and Client locally
    • Nb: In Visual Studio with a template from GitHub you can create, build and test, and commit a C# API with a Blazor WASM app.
  • Staging environment
    • When generated by GitHub Actions can be deployed to a staging environment on Azure
  • Built-in access to a variety of authentication providers and custom routes
    • eg Fallback routes form when route not found
    • Can limit routes for if logged in or not
  • Enterprise ready

What’s new since Public Preview

  • More font-end frameworks
    • Blazor WebAssembly
    • Jekyll
      Got to try that!
  • More Functions languages
    • Besides Node
    • .NET Core 3.1
    • Python 3.8
  • Azure Devops task
    • Previously just GitHub Actions
  • Increased platform limits
    • eg No. of files
  • New Config File
    • routes.json staticwebapps.config.json
    • Wildcards with extensions
    • Better fallback routes
    • Per route headers
  • App Insights Integration
  • Static Web Apps CLI
    • Need to link the function and client apps
    • Previously need environment variable/s which are code platform dependent .. messy
    • Install the npn Azure Static Web Apps CLI (SWA CLI)
    • Can run the function app with this then just refer to it under /api/GetProducts

Viz Storage Web Apps

Azure Storage Static web sites support storing massive (see here) amounts of unstructured data such as videos and images whereas SWAs are limited to 250M/500M for Free/Standarrd SKUs. See Tutorial: Host a static website on Blob Storage. Nb: This blog site is a Storage Static Web Site. It is built and deployed from Azure Devops to Blob Storage.

SWA Pros

  • Simplified build and deployment process
    • Static Web Apps (SWA) are better because it-all-just-works.
    • Its turnkey. No need to manually configure any additional components.
    • You follow the standard (simple) steps to setup the app on Azure and in GitHub and commit changes, and the updated app will be built and deployed to Azure.
  • Functions in the same repository
  • TLS cert management (free!)
  • Automated preview environments
  • APIs that are scaled and hosted with your static content
  • Content and corresponding APIs logically versioned together

Nb: Some of these points are from a StackOverflow discussion.

GA 12 May 2021

  • Support for apex/root domains
  • Standard plan
    • In Preview only Free Plan was available.
    • Added Standard Plan for production ready applications.
    • 10 sites for Azure Functions and Staging World Wide (Standard, 3 for Free)
Plan-Features Free Standard
  For hobby or personal projects For general purpose production apps
Price Free Calculate price eg. $9 per app per month
Included bandwidth 100GB per subscription 100GB per subscription
Bandwidth overage - $0.20 per GB
Custom domains 2 per app 5 per app
SSL certificates Free Free
Custom authentication - ✔
Max app size 250MB 500MB
Staging environments 3 10
Azure Functions Managed Managed or Bring your own
Deployment Size 250MB 500 MB
SLA - 99.95%

Azure Functions

About

Azure Functions are light-weight severless cloud computing “parcels” that allow a small piece of code (as small as one function) to be deployed to Azure and executed upon demand. They are scalable in that as demand increases so do the resources given to it on Azure. Upon failure though, all extra resources wil get released. Azure functions can be written in multiple languages such as C#, Java, JavaScript, TypeScript, and Python. For development purposes, an Azure Function can be authored in Visual Studio (or VS Code) and run there before being deployed to Azure. The code for a function within an Az Function will have a trigger; for example a Http trigger. Note that an Az Function can have multiple triggers / multiple paths to triggers. For example, an Az Function may have a api path to a HttpTrigger paths a database’s Get, Post, Put and Delete, each a separate function with.

Quickstart: Create your first function in Azure using Visual Studio

In Visual Studio you can develop an Az Function as part of an SWA solution or on its own. When you run an Http triggers Az Function from VS, either way, you get a localhost:port Url to it. You then get the api route specified and a Verb for each trigger in the function. For example:

        [FunctionName("ActivitysGet")]
        public async Task<IActionResult> Run(
            [HttpTrigger(AuthorizationLevel.Anonymous, "get", Route = "activitys")] HttpRequest req)
        {}
        [FunctionName("ActivitysPost")]
        public async Task<IActionResult> Run(
            [HttpTrigger(AuthorizationLevel.Anonymous, "post", Route = "activitys")] HttpRequest req,
            ILogger log)
        {}

…lead to …

Functions:

        ActivitysGet: [GET] http://localhost:7071/api/activitys

        ActivitysPost: [POST] http://localhost:7071/api/activitys

You can then make direct calls the function using Curl (sending and receiving Json strings) or make calls in the SWA client code such as:

        activitys = await http.GetFromJsonAsync<IEnumerable<Activity>>("api/activitys");
  //And
        await http.PostAsJsonAsync("api/activitys", activity);

GA

When Azure Static Web Apps were in preview, the Free SKU was all that was available. This only permits Az Functions with Http Triggers. With GA, the Free version remains so restricted but the Standard SKU Az Functions can be bring-your-own in that they are not part of the deployed SWA and run quite separately and communicate with an SWA as Http Endpoints. Also these functions can have other triggers besides Https.

Nb > When you use a byo function, when setting up an SWA on Azure, you set the api_location blank and you can only have one.

  • Azure Function Triggers in a Free SWA are still limited to Http. static-web-apps/front-end-frameworks)
  • Managed functions: By default, the API of a static web app is an Azure Functions application managed and deployed by Azure Static Web Apps associated with some restrictions.
  • Bring your own functions: Optionally, you can provide an existing Azure Functions application of any plan type, which is accompanied by all the features of Azure Functions. With this configuration, you’re responsible to handle a separate deployment for the Functions app.
    • Nb: Only supported in the Static Web Apps production environment.
  • Bring your own functions
Feature Managed Functions Bring your own Functions  
Access to Azure Functions triggers Http only All
Supported runtimes Node.js, .NET, Python All  
Supported Azure Functions hosting plans Consumption Consumption, Premium, Dedicated  
Integrated security with direct access to user authentication and role-based authorization data ✔ ✔  
Routing integration that makes the api route available to the web app securely without requiring custom CORS rules. ✔ ✔  
Durable Functions programming model   ✔  
Managed identity   ✔  
Azure App Service Authentication and Authorization token management   ✔  
API functions available outside Azure Static Web Apps   ✔  
 TopicSubtopic
   
 This Category Links 
Category:Web Sites Index:Web Sites
  Next: > Jekyll
<  Prev:   Azure Static Web App