C'est quoi une Azure Static Web App?

Cet article fait partie de la série Azure Static Web Apps avec Blazor.

Un exemple complet et fonctionnel est disponible ici : mongeon/code-examples · azure-swa-blazor/01-getting-started.

Quand on a un projet Blazor WebAssembly à déployer, on pense souvent à Azure App Service par réflexe. C’est correct, ça marche, mais c’est un peu comme louer un camion pour livrer une enveloppe. Blazor WASM, une fois compilé, c’est juste des fichiers statiques. Pas besoin d’un serveur .NET derrière.

Azure Static Web Apps (SWA) existe exactement pour ça. Le service héberge vos fichiers statiques sur un CDN global, gère le HTTPS automatiquement, et s’intègre avec GitHub pour le déploiement continu. Le tier gratuit est assez généreux pour la plupart des projets personnels ou des prototypes.

C’est quoi la différence avec App Service?

App Service c’est un serveur applicatif complet. Votre code tourne dans un processus sur une VM quelque part. Vous payez pour du compute, même si votre app fait rien.

Static Web Apps c’est un hébergement de fichiers statiques distribué sur un CDN. Il n’y a pas de serveur .NET qui tourne. Votre Blazor WASM est servi comme du HTML, du CSS et du WebAssembly directement au navigateur. Si vous avez besoin d’un backend, SWA peut brancher des Azure Functions, mais on va couvrir ça dans un prochain article.

Pour un projet Blazor WASM standalone, SWA est plus simple, moins cher, et souvent plus rapide grâce au CDN.

Créer le projet Blazor WASM

On part avec un projet standalone. Pas de hosted template, parce que SWA gère le backend séparément avec Azure Functions.

dotnet new blazorwasm -n Client -o Client

Ça nous donne un projet Blazor WASM de base avec les pages Counter et Weather. Rien de fancy, mais c’est tout ce qu’il faut pour tester le déploiement.

La structure du projet ressemble à ça :

Client/
  Pages/
    Counter.razor
    Home.razor
  wwwroot/
  Program.cs
  Client.csproj

Avant d’aller plus loin, testez que ça roule localement :

cd Client
dotnet run

Vous devriez voir l’app sur https://localhost:5001 (ou le port affiché dans votre terminal).

Le fichier staticwebapp.config.json

Blazor WASM est une single-page application (SPA). Quand un utilisateur navigue vers /counter, il n’y a pas de fichier counter.html sur le serveur. Il faut que toutes les requêtes retombent sur index.html pour que le router de Blazor prenne le relais.

Ajoutez un fichier staticwebapp.config.json dans le dossier wwwroot de votre projet :

{
  "navigationFallback": {
    "rewrite": "/index.html"
  }
}

Sans ce fichier, un refresh sur /counter va retourner un 404. On va explorer ce fichier de config en détail dans le prochain article de la série, mais pour l’instant c’est tout ce qu’on a besoin.

Déployer sur Azure depuis GitHub

Poussez votre code dans un repo GitHub si c’est pas déjà fait. Ensuite, dans le portail Azure :

Créer la ressource en cherchant “Static Web Apps” dans le marketplace. Choisissez le tier Free pour commencer.

Connecter votre repo GitHub dans la section de déploiement. Azure va vous demander l’organisation, le repo et la branche.

Configurer le build en sélectionnant le preset “Blazor” dans les Build Details. Les valeurs importantes :

App location : le chemin vers votre projet Blazor (par exemple Client si votre .csproj est dans un sous-dossier Client)
Output location : wwwroot

Azure va automatiquement créer un workflow GitHub Actions dans votre repo. Ce workflow va compiler et déployer votre app à chaque push sur la branche configurée.

Le workflow GitHub Actions

Après avoir créé la ressource, allez voir dans votre repo GitHub, il y a un nouveau fichier dans .github/workflows/. Le workflow généré ressemble à ça (simplifié) :

name: Azure Static Web Apps CI/CD

on:
  push:
    branches:
      - main
  pull_request:
    types: [opened, synchronize, reopened, closed]
    branches:
      - main

jobs:
  build_and_deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build And Deploy
        uses: Azure/static-web-apps-deploy@v1
        with:
          azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN }}
          repo_token: ${{ secrets.GITHUB_TOKEN }}
          action: "upload"
          app_location: "Client"
          output_location: "wwwroot"

Le secret AZURE_STATIC_WEB_APPS_API_TOKEN est ajouté automatiquement dans votre repo par Azure lors de la création de la ressource. Vous n’avez rien à configurer manuellement.

Une fois le workflow exécuté, votre app est disponible sur une URL du genre https://lively-moss-123456.azurestaticapps.net. Pas de configuration DNS, pas de certificat SSL à gérer.

Vérifier que ça marche

Allez sur l’URL fournie par Azure. Vous devriez voir votre app Blazor. Cliquez sur Counter, incrémentez le compteur, puis rafraîchissez la page. Si vous avez bien mis le staticwebapp.config.json, la page recharge correctement au lieu d’afficher un 404.

Si vous voyez un 404 sur le refresh, vérifiez que le fichier staticwebapp.config.json est bien dans wwwroot et qu’il est inclus dans la publication.

Dans le prochain article, on va explorer le fichier staticwebapp.config.json en profondeur : les routes, les redirections, les headers de sécurité, et comment protéger certaines pages.

Articles de la série

C’est quoi une Azure Static Web App? (Cet article)
Le fichier staticwebapp.config.json
Brancher une API Azure Functions
L’authentification intégrée de SWA
Développer localement avec le CLI swa
Les preview environments sur les PR

Bon déploiement, et profitez-en, le tier gratuit est pas mal généreux.

Cet article a été rédigé avec l’aide de l’IA et révisé par moi.