Blazor : hébergement

Un composant Blazor s'écrit une seule fois, mais peut s'exécuter à plusieurs endroits. La vraie question d'architecture : où tourne ton C#, sur le serveur ou dans le navigateur ? On boucle la série démarrée avec les composants.

# Blazor Server

Le composant s'exécute sur le serveur. Le navigateur ne garde qu'un fil temps réel (SignalR sur WebSocket) : chaque interaction remonte au serveur, qui calcule le diff du DOM et renvoie uniquement ce qui change.

• Points forts : démarrage quasi instantané (rien à télécharger), accès direct à la base de données et aux services serveur, client très léger.
• Limites : une connexion permanente obligatoire, une latence réseau à chaque interaction, et un état qui vit en mémoire serveur (coûteux à grande échelle, sensible aux coupures).

# Blazor WebAssembly

Le composant s'exécute dans le navigateur : le runtime .NET est compilé en WebAssembly et téléchargé au premier chargement. Ton C# tourne côté client, là où tournerait du JavaScript.

• Points forts : interactions instantanées (aucun aller-retour serveur), fonctionnement hors-ligne possible (PWA), serveur déchargé (ce ne sont que des fichiers statiques).
• Limites : téléchargement initial plus lourd (runtime + assemblies), pas d'accès direct à la base (il faut passer par une API), et tout le code envoyé au client est visible.

# Les render modes (.NET 8+)

Historiquement, il fallait choisir Server ou WebAssembly pour toute l'application. Depuis .NET 8, le choix se fait composant par composant via @rendermode :

@page "/compteur"
@rendermode InteractiveAuto

<button @onclick="() => count++">Clics : @count</button>

@code { private int count = 0; }

@page "/compteur"

@rendermode InteractiveAuto

<button @onclick="() => count++">Clics : @count</button>

@code { private int count = 0; }

InteractiveAuto offre le meilleur des deux mondes : premier affichage rapide via Server, puis bascule transparente vers WebAssembly pour les visites suivantes.

# Et Blazor Hybrid

Quatrième option : Blazor Hybrid. Les composants tournent nativement dans une app de bureau ou mobile (.NET MAUI, WPF, WinForms) et s'affichent dans un BlazorWebView. Le C# s'exécute en process natif, sans WASM ni serveur.

# Server vs WebAssembly en un coup d'œil

# À retenir

• Un même composant, plusieurs hébergements : la question centrale est où s'exécute ton C#.
• Server : léger et branché au serveur, mais latence réseau et connexion permanente.
• WebAssembly : autonome et instantané côté client, mais téléchargement initial plus lourd.
• .NET 8 unifie tout via les render modes par composant (InteractiveAuto combinant les deux) ; Hybrid ajoute le natif.

Ceci clôt le set de démarrage Blazor / Razor. La suite de la série (cycle de vie, formulaires et validation, injection de dépendances, JS interop) viendra approfondir chaque brique.