Blazor WebAssembly : les différences avec Blazor Server en un coup d’œil

Je vous présente aujourd’hui Blazor WebAssembly et ses différences avec Blazor server. Après un rappel de ce qu’est Blazor, nous pourrons entrer dans les détails avec un exemple présentant la mise en place d’une application Blazor WebAssembly à travers Visual Studio.

Qu’est-ce que Blazor ?

Quand vous naviguez sur une page internet, vous avez souvent des interactions avec la page, que ce soit par le biais de formulaires, de pop-up ou de boutons d’interaction divers et variés. Il y a quelques années, le seul moyen de faire cela était de passer par un framework JavaScript (Angular, React, Vu etc.). L’arrivée de Blazor a changé la donne : vous avez maintenant la possibilité d’utiliser du .NET pour réaliser l’intégralité de votre site, pour le back et pour le front. Il est ainsi possible de remplacer toutes les interactions, qui autrefois étaient l’apanage de JavaScript, par du C#. Pour plus d’informations, je vous renvoie vers le site de Blazor.

 

Blazor Server et Blazor Webassembly

Blazor Server est une application qui tourne sur un serveur. Tout le code C# est exécuté sur un serveur. Le client ne contient que du HTML, CSS et JavaScript, aucun code C# ne va dans le client. Les échanges avec le serveur s’effectuent via une connexion SignalR. Les changements sont envoyés sur le serveur et le nouveau rendu est envoyé en retour.

À la différence de Blazor Server, toute l’application s’exécute dans le client avec Blazor WebAssembly. Le C# est donc exécuté dans le client sur la machine et non plus un serveur. Le code est compilé dans une DLL envoyée au client qui va s’en servir pour fonctionner. Il est ainsi possible de réaliser une application fonctionnant entièrement hors ligne. La philosophie ici est de faire une application qui n’a pour seule vocation que d’afficher des informations à un utilisateur. Les données sont quant à elles récupérées sur un serveur via des API. Il ne doit pas y avoir de logique métier ou d’accès aux données dans une application Blazor WebAssembly. Parmi les raisons pour lesquelles il est déconseillé de faire d’accès aux données directement, la sécurité : faire transiter une chaîne de connexion, par exemple, n’est pas sécurisé.

 

Les premiers pas avec Blazor Webassembly

Pour créer une application Blazor WebAssembly, il faut avoir la version .Net Core 3.1. Ensuite il suffit de lancer Visual Studio et de choisir comme nouveau projet une application Blazor.

Donnez ensuite un nom au projet.

On a ensuite le choix entre créer une application serveur Blazor ou une Blazor WebAssembly App. C’est bien sur la seconde qu’il faut choisir.

Dans la partie de droite, on dispose également de plusieurs options de configuration. Il est ainsi possible de choisir une authentification, de créer un serveur Asp.NET Core associé, et de choisir directement de créer une Progressive Web App (PWA).

On a donc notre projet de créé.

Si maintenant on l’exécute, on se retrouve avec un site qui ressemble beaucoup à la version serveur de Blazor.
 


Différences avec l’application serveur

La première chose que l’on constate, c’est que les projets serveur et WebAssembly sont légèrement différents au niveau de leur constitution.

Concentrons-nous sur le projet WebAssembly. L’application commence par le fichier Program.cs.

Dans un projet WebAssembly, on initialise un builder WebAssemblyHostBuilder. On définit l’élément racine comme étant app. App est le routeur de Blazor. Si la route indiquée est correcte, il l’affiche en utilisant le layout par défaut (qui est le fichier MainLayout.razor), sinon il affiche un message indiquant que la route n’existe pas.

Ensuite on initialise un service HttpClient qui permettra de communiquer avec le serveur et les API, puis on l’exécute de manière asynchrone. Il est intéressant de noter que l’initialisation des services se fait ici dans Program.cs alors qu’il se fait dans le fichier startup.cs pour la version Blazor Server.

Par ailleurs, le corps HTML est défini dans le fichier index.html présent dans le dossier wwwroot. Il remplace le fichier _Host.cshtml de Blazor Server. Lorsque l’on regarde les pages, on constate qu’elles sont similaires aux pages de la version serveur. Par exemple, la page Counter.razor est exactement la même. Il s’agit là d’un point extrêmement intéressant, car on constate tout de suite qu’il est possible de réaliser des composants qui seront utilisés à la fois dans la version Server et dans la version WebAssembly.

Et voilà. Si vous êtes déjà à l’aise avec Blazor Server, alors vous connaissez 99% de Blazor WebAssembly.


Serveur ASP.NET core et code partagé

Lors de la création de l’application Blazor WebAssembly, il est possible de cocher la case Asp.NET Core hosted. Cela permet de créer directement le serveur qui sera associé à notre application.

Dans l’explorateur de solution, trois projets sont disponibles lorsque l’on choisit d’avoir un serveur .Net Core.

 

Le projet qui nous intéresse ici est le troisième : BlazorWa.Shared. C’est un projet très intéressant qui porte bien son nom. En effet, il permet de partager du code entre le serveur et le client. Il est souvent utilisé pour partager des objets métier par exemple, afin de s’assurer d’une cohérence et d’une continuité entre le client et le serveur. Il est possible par ce biais de définir des règles de validations qui seront utilisées par le client et par le serveur. Ceci apporte de la robustesse et de la cohérence, les deux projets utilisant exactement les mêmes règles.

 

Que choisir : Blazor Webassembly ou Blazor Server ?

Avec Blazor Server, tout le calcul s’effectue sur le serveur. Aucun code C# n’est accessible à l’utilisateur final. Chaque partie contenant du C# est compilée et analysée sur le serveur, et seule une page HTML est envoyée pour le rendu. Blazor WebAssembly compile le code dans une DLL qui est envoyée dans le navigateur. Il est donc possible de voir le code C# dans le client.

C’est notamment pour cela qu’il est possible d’accéder directement à la base de données dans Blazor Server et fortement déconseillé de le faire avec Blazor Web Assembly (il s’agit d’une importante faille de sécurité). Pour Blazor WebAssembly, il faudra passer par des API intermédiaires (ce qui n’est pas forcément un problème, surtout quand ces dernières existent déjà).

Par ailleurs, tous les calculs étant réalisés sur le serveur dans le cas de Blazor Server, il faut dimensionner le serveur en conséquence, et un grand nombre de requêtes en simultané peut affecter les performances du site (chaque utilisateur va ouvrir une nouvelle connexion SignalR). À l’inverse, dans le cas de Blazor WebAssembly, c’est le navigateur qui se charge du calcul. Il faut donc que la machine du client soit suffisamment performante. Mais dans ce cas, il n’y aura pas plus d’impact sur les performances si 1 million de personnes consultent le site qu’un utilisateur seul. L’impact se fera au moment de télécharger la DLL dans le navigateur. Mais une fois téléchargé, c’est chaque client qui fera les calculs sans être impacté par les autres. (C’est le même principe pour les frameworks JavaScript comme Vu ou React). Autre point, seul Blazor WebAssembly permet de faire une Progressive Web App. Si votre application nécessite une utilisation hors ligne, alors vous devez utiliser Blazor WebAssembly.

Vous avez maintenant le choix de sélectionner la version qui correspond le plus à vos besoins ?

Retrouvez également mes précédents articles sur Blazor.