Les WebAssembly : le comprendre à travers le framework Blazor

Bien vouloir lire aussi et de preference d'abord:

Comprendre les SPA(Single page Application)

Qu'est ce que les webassembly et pourquoi il faut le marquer à l'oeil?

L'architecture des web Assembly: allons plus en details

Les SPA(Single Page Application) avec le framework Blazor de dotnet : les differents <<Hosting Model >>.

Dans mon post d'hier ici,  j'ai parlé des webassembly(wasm), j'ai évoqué ses fonctionalités et je vous décrivais  dans ce post qu' il faut  prendre cette nouvelle technologie très au serieux car c'est l'alternative qu'on peut utiliser pour faire du web en utilisant completement autres langages en dehors du javascript meme pour des opérations qui le plus souvent sont typiquement frontend. Dans ce post je vous ai parlé du framework blazor de dotnet qui dejà exploite les wasm pour faire des SPA completement en dotnet et c#.

Un SPA donc j'ai longuement parlé dans mes post, n'est rien d'autre qu'une page web qui peut mettre une partie de son contenu à jour de manière asincrone en faisant des requetes HTTP au serveur web sans besoin d'une mise à jour complete de toute la page, ce qui rend la page <<UserFriend ou fluide>> pour l'utilisateur et l'application se comporte un temps soit peu comme une application desktop.

le framework blazor utilise deux modèles de developpement pour mettre en place la SPA(ce qu'on appelle en anglais le hosting model).

=>Blazor Server(image 1) :c'est le premier modèle mis sur pied par Microsoft qui est présent depuis la version 3 de dotnet core, dans ce model comme on peut le voir dans l'image 1, la app SPA est executée coté serveur et non dans le navigateur et seulement les mises à jour sont fait dans le navigateur, toute la logique de mise à jour du HTML est fait à partir du serveur à travers ASP.NET Core SignalR qui est basé sur des <<web socket>>... trop de mots difficile n'est ce pas? cherchons à entrer un peu en profondeur et pas à pas.

Le protocole HTTP est basé sur une connection TCP (Tranfert Control Protocol), j'ai parlé ici sur ma page de la PILE OSI pour vous expliquer comment les données sont effectivement empilées et transferées d'une machine A sur le web à une autre machine B sur le web, les données au niveau plus bas sont decoupées en petit paquets(byte) et aiguillées sur les cables qui traversent les switch et les routeurs, les petits paquets peuvent suivre des chemins differents et doivent etre reconstruit quand tous les paquets sont collectés sur le serveur, cela est fait grace à TCP et pour nous developeurs, c'est transparent, mais pour le systhème d'exploitation et les appareils de reseaux en mi-chemin ce n'est pas transparent, et le connaitre nous permet de mieux reflechir quand on veut projecter un software.

Pour faire comuniquer deux applications (dans le system d'exploitation on parle de processus car une application pour le system d'exploitation est un processus) entre elle que ce soit sur la meme machine ou dans les machines distantes, on le fait à travers ce qu'on appelle des <<socket>>, donc les socket ce sont des voies de communications ou des canaux par lesquels on fait communiquer deux applications, donc HTTP utilise TCP qui ouvre un socket entre la machine ou il y a le navigateur et la machine serveur (donc entre les deux systheme d'exploitation des deux machines) pour vehiculer les données qui contient le HTML, cette connexion est mono-directionnelle, c'est à dire que c'est la machine du navigateur(client) qui ouvre cette connexion, le serveur repond en donnant le contenu demandé puis ferme la connexion, donc l'ouverture de la connexion est dans un seul sens.

Par contre il y a souvent necessité d'ouvrir la connexion dans les deux sens c'est à dire une connexion peut etre initiée aussi à partir du serveur et non pas seulement par le client, dans ce cas on parle de connexion bidirectionnelle, c'est le cas par exemple des chat avec les messageries comme whatsapp, quand vous recevez un message, ça vient du serveur et non de la personne qui vous a envoyé le message, du moins la persone envois le message au serveur de la chat, puis meme si vous dormez, le serveur doit vous envoyez le message donc il doit initier lui aussi une connexion et ne pas à attendre que vous ouvrez votre whatsapp pour en demander donc la communication est bidirectionnelle dans ce cas et si on le fait par le web, on parle donc des web socket donc communication bidirectionnelle, SignalR est donc le framework dotnet pour faire les web socket et du coup Blazor server l'utilise donc pour pouvoir à partir du serveur mettre à jour la page web en guardant plutot sur le serveur la logique metier pour cette mise à jour et non plus sur le navigateur comme le font les autres framework frontend, le plus gros avantage ici est que le demarage de l'application est ultra rapide car le navigateur ne doit rien telecharger, le plus gros désavantage étant qu'il faut que l'utilisateur ait toujours à 100% la connection internet car la logique etant coté serveur, sans connection rien ne fonctionne et on ne peut donc pas transformer la web app en PWA.

 

=>Blazor WebAssembly (image 2): dans ce modele, on utilise le wasm pour faire la SPA, comme je vous ai expliqué dans l'article precedent, le wasm est un format binaire standardisé qu'on peut executer en JIT(Just In Time Compilation) dans le navigateur du coup blazor trasforme le site web asp.net MVC razor en format wasm ensemble avec le runtime de .net qu'on appelle mono et quand l'utilisateur demande la page SPA, le runtime mono sert la page en creant son propre DOM qu'on appelle dans le jargon <<renderer tree>> du moins c'est un virtual DOM qui est exclusivement geré par le runtime de dotnet, et chaque fois que l'utilisateur interagit avec la page, ce virtual DOM est comparé au vrai DOM javascript du navigateur et seulement la partie qui a été modifiée est mise à jour exactement comme ça se passe avec react ou vuejs qui sont basés sur le virtual DOM, mais eux ils utilisent le javascript pour faire la logique de mise à jour tandis que ici blazor utilise c# et les technologies dotnet pour le faire.

j'esperes que cet eclaircissemnt aidera tous ceux qui font leur pas dans les SPA et dans les webAssembly , dans le prochain article on fera une application complete pas à pas avec blazor en PWA, l'application qu'on a fait sur la meteo en PWA mais cette fois ci on le fera en blazor

Happy Coding

---

---

Share

Comments (0)

Leave A Comment

Your Name:
Comment: