Aperçu de Blazor Webassembly

Aperçu de Blazor Webassembly

Le but de cet article sera de présenter brièvement les nouveautés de blazor Webassembly et les différences existantes avec Blazor server. Après un bref 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.

Rappel sur Blazor

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 popup ou de bouton d’interactions 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.).

Cela change avec l’arrivée de blazor. 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 autre fois était réservé au JavaScript par du C#.

Pour plus d’informations, je vous renvoie vers le site de Blazor.

Blazor Serveur

Il s’agit d’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.

Blazor WebAssembly

À la différence de Blazor server, toute l’application s’exécute dans le client. Le C# est 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 à elle 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.

Une des raisons pour lesquelles il ne faut pas faire d’accès aux données directement, c’est qu’il ne serait pas sécurisant de faire transiter une chaine de connexion par exemple.

Introduction à Blazor WebAssembly

Premiers pas

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.

Il faut ensuite donner 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 cette dernière 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. Je parlerai plus en détail des applications pwa avec Blazor dans un prochain article. Aujourd’hui, je ne vais parler que de Blazor webasembly, je ne vais donc pas cocher les cases ASP.NET Core hosted ni Progressive Web Application.

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.

public class Program
    {
        public static async Task Main(string[] args)
        {
            var builder = WebAssemblyHostBuilder.CreateDefault(args);
            builder.RootComponents.Add<App>("app");

            builder.Services.AddScoped(sp => new HttpClient { BaseAddress = new Uri(builder.HostEnvironment.BaseAddress) });

            await builder.Build().RunAsync();
        }
    }

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 apis.  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 serveur.

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 Serveur.  

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 serveur 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 très 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.

Blazor WebAssembly ou Blazor server

Blazor serveur, 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 analyser sur le serveur et seul une page HTML est envoyé pour le rendu.

Blazor webassembly compile le code dans une dll qui est envoyé 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 apis 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 webssembly, 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 Framework JavaScript comme vu ou react).

Autre point, seul Blazor webassembly permet de faire une progressive web application. 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 🙂

Laisser un commentaire