Ce code bas niveau étant interprété côté navigateur peut être écrit dans différents langages comme le C, C++, RUST, x86 etc.

L’interprétation du Web Assembly se fait plus bas-niveau que celle du Javascript. Web Assembly utilise de manière plus efficace et directe les ressources disponibles sur la machine sur laquelle il s’exécute (CPU/Mémoire), et permet donc d’atteindre un haut niveau de performances.

Ces performances accrues permettent alors de développer des applications qui n’étaient pas envisageables en Javascript. Par exemple du traitement vidéo en temps réel, comme le floutage d’arrière plan en visio-conférence, ou encore des jeux vidéo.

Pour résumer, WASM a été créé pour tirer parti de la puissance des langages de bas niveau, couplé à la flexibilité de Javascript afin de créer des applications Web plus performantes.

Un peu de contexte

WASM fut officiellement lancé en 2015 pour la première fois sous forme d’une démonstration faite sous Unity (moteur de jeu multi plateforme) afin de démontrer les performances et les possibilités de l’outil.

Mozilla a sorti asm.js, le 21 mars 2013, un sous-ensemble du langage JS pour améliorer les performances grâce à une couche de traitement binaire. Google et Lars Bak ont mis en place un moteur JS V8, le 2 septembre 2008, qui peut compiler nativement vers de l’assembleur. Ces deux derniers événements sont surtout des améliorations liées à la gestion du langage.

Objectifs

Les objectifs du WASM sont:

• la rapidité : avoir des performances proches des applications natives (C/C++/Rust) tout en fonctionnant sur un navigateur Web..
• la portabilité : WebAssembly est conçu de manière à s’associer aux autres technologies web mais aussi de garantir une rétro compatibilité ascendante entre les différentes versions.
  Il existe aussi des polyfills pour les navigateurs plus anciens.
• la sécurité : l’environnement dédié permet de garantir une isolation totale du code et de la machine de l’utilisateur. Par exemple, la partie entrée / sortie (réseau et fichier) est totalement inaccessible (en dehors du module qui l’embarque).

La compilation

Fig: Le processus de compilation Web Assembly

Afin d’exécuter du Web Assembly dans une page web, il faut compiler du code écrit dans un langage source (écrit en C, C++, Rust ou autre) vers un code intermédiaire (le bytecode WASM). Le bytecode est situé entre le code d’un langage source et le code machine (binaire). Cela est rendu possible grâce à une infrastructure de compilation LLVM, qui implémente la traduction d’un AST (arbre de syntaxe abstraite) en bytecode WASM.
Le fichier ainsi compilé aura pour extension ‘.wasm’.

L’utilisation d’une LLVM permet d’isoler et d’uniformiser la compilation de tous les langages sources supportés vers ce format. Pour ajouter le support d’un langage, il suffit d’implémenter un programme capable de lire un AST pour le transmettre à la LLVM (transpilateur).
Il est donc possible de créer des compilateurs pour n’importe quel langage. (une liste des langages principaux déjà supportés par WASM se trouve sur le Discord de sa communauté.)

Fonctionnement général du Web Assembly

Le code initialement écrit dans un langage haut-niveau est donc compilé dans en un module web-assembly. La compilation produit un fichier binaire ‘.wasm’ contenant le bytecode devant être exécuté dans le navigateur web de l’utilisateur. Les fichiers ‘.wasm’ peuvent alors être distribués aux utilisateurs comme le reste des ressources statiques d’une application web.

Lorsqu’un utilisateur consulte l’application web, les ressources statiques (HTML, CSS, Images) sont téléchargées par son navigateur, ainsi que le code Javascript et les binaires ‘.wasm’. Le navigateur se charge de décoder, compiler et exécuter le code WASM, en parallèle du code Javascript habituel.

Les concepts

• Intégration sur le web WebAssembly est conçu de manière à facilement s’associer aux autres technologies web et de garantir une rétrocompatibilité.
• Le fichier compilé est téléchargé, l’exécution est faite nativement sur le poste de l’utilisateur et la mémoire est gérée de manière linéaire.
• Bien que l’exécution ait lieu sur le poste de l’utilisateur, WASM ne permet pas l’accès à certains composants du kernel : Il existe une limite sur la gestion des entrées/sorties. (pour des raisons de sécurité)
• Mémoire linéaire La mémoire linéaire est une seule plage d’adresse mémoire sur laquelle on peut agir au fil de l’eau. Vu l’abstraction du sujet, il est mieux de pouvoir se représenter tout ça. Voici un parallèle entre la manière dont est gérée la mémoire en Java (de Jakob Jenkov) et un schéma de la mémoire linéaire (de Meghalee Goswami) :

Avant d’aller à la suite un petit aparté : WASM a mis en place un traducteur du fichier compilé nommé Web Assembly Text (WAT). Le fichier compilé est donc lisible

• Module Représente un binaire WASM qui a été compilé en code exécutable par le navigateur.
• Table Représente un tableau typé de référence ne pouvant être stocké de manière brute en mémoire (pour des raisons de sécurité et de portabilité).
• Instance Représente un module associé ainsi que ses états (la mémoire, la table ainsi qu’un ensemble de données importées).

Les cas d’usage de WASM

Comme expliqué en introduction, WASM permet un haut niveau de performances impossible en Javascript. Ces performances ouvrent la possibilité d’implémenter de nouveaux cas d’usage. Certains de ces cas d’usage sont concrets et déjà mis en place dans certaines applications et jeux. D’autres cas d’usage sont plutôt de l’ordre du POC (Proof Of Concept) ou de la démo :

• Server-side rendering
• OCI (Open Container Initiative)
• 3D Web View Rendering
• Étendre des fonctions JS
• Extensions navigateurs (ublock origin)
• Utilisation de la 3D

Voici des exemples d’applications connues faites à l’aide de WASM :
Figma, Google Earth, Unity, Unity, etc.

Pros

• Performance
• Cross platform
• Sécurisation
• multiples langages Rust / C++ / C etc.
• Portabilité

Cons

• Communauté faible
• Beaucoups de concepts complexe à appréhender avant de pouvoir faire la moindre chose
• N’a pas encore percé malgré son “âge”
• Installation plus ou moins aisée en fonction de la plateforme de développement
• Pas “user friendly”

Conclusion

Le principal but de WASM est d’apporter un enrichissement de la stack technique de Javascript avec un haut niveau de performances. La plus grande difficulté de WASM reste d’assimiler ses différents principes et concepts généraux

• devoir utiliser un langage de bas niveau
• utiliser un compilateur
• avoir affaire à une communauté de niche
• assez complexe à appréhender Malgré une adoption encore faible, il n’en reste pas moins fiable que ce soit en termes de sécurité, de performance, de lisibilité et dans certains domaines la seule solution possible afin de garantir un haut niveau de performance sur une application Web.

Lexique

• bytecode: En informatique, le bytecode (terme anglais signifiant « code en bytes ») est un code intermédiaire entre les instructions machines et le code source, qui n’est pas directement exécutable. Le bytecode (également appelé code portable ou p-code) peut être créé à la volée et résider en mémoire (compilation à la volée, JIT en anglais) ou bien résider dans un fichier, généralement binaire qui représente le programme, tout comme un fichier de code objet produit par un compilateur. Source
• Arbre de syntaxe abstraite: Un arbre de syntaxe abstraite (AST) est une manière de représenter la syntaxe d’un langage de programmation sous la forme d’une structure arborescente hiérarchique. Cette structure est utilisée pour générer des tables de symboles pour les compilateurs et la génération de code ultérieure. L’arbre représente toutes les constructions du langage et leurs règles ultérieures. Source
• LLVM: LLVM (anciennement appelé Low Level Virtual Machine en français : « machine virtuelle de bas niveau ») est une infrastructure de compilateur conçue pour l’optimisation du code à la compilation, à l’édition de liens, voire à l’exécution ou durant les « temps morts » d’un programme, quel que soit le langage d’origine. LLVM permet de créer une machine virtuelle pour des langages similaires à Java et sa JVM, un générateur de code pour une architecture matérielle spécifique, et des optimiseurs de compilation indépendants de toute plate-forme et de tout langage. Source
• Kernel: terme anglais signifiant « noyau ». Il constitue le cœur du système qui exploite un ordinateur. Il établit la communication entre la partie matérielle et la partie logicielle de l’appareil. Source

Sources

The state of WebAssembly (2022)

• https://tech.mozfr.org/post/2017/03/08/D-ou-vient-la-rapidite-de-WebAssembly
• https://developer.mozilla.org/fr/docs/
• https://emscripten.org/
• https://developer.mozilla.org/fr/docs/
• https://jenkov.com/tutorials/java-concurrency/java-memory-model.html
• Angry Bots Démo
• lien discord Wasm
• Applications faite en WASM
• OCI (Open Container Initiative)
• schéma mémoire linéaire de Meghalee Goswami

Les “Design Patterns”, ou “patrons de conception”, sont un ensemble de solutions reconnues, particulièrement dans la programmation orientée objet, comme étant la meilleure réponse afin de résoudre un problème de conception récurrent.

Les exemples de patrons peuvent être faits de différentes façons: par le biais de schémas, de pseudo code, la manière d’organiser ses modules ou classes ou à l’aide d’une implémentation proposée.

D’où viennent-ils ?

Nous pouvons être redevable à Christopher Alexander, anthropologue et architecte Américain pour avoir travaillé sur “la théorie des Pattern Languages” permettant des déclinaisons dans des domaines aussi divers que l’histoire de l’art, l’anthropologie…
Cette façon d’aborder le modèle de conception a été reprise en 1987 par Kent Beck (concepteur d’extrême programming) et Ward Cunningham (inventeur du concept de Wiki) , qui ont décidé d’appliquer ce type de design architectural à l’informatique.
C’est en 1994, à la suite d’un livre nommé Design Patterns: Elements of Reusable Software co-écrit par un collectif (GoF pour Gang of Four) et décrivant plus d’une vingtaine de patrons que ce principe fut réellement reconnu.

Voici les différents types de patrons de conception :

Le patron de création (Creational Pattern)

Il a pour but d’aider à résoudre les problèmes d’instanciation de classes.

Quelques exemples:

• Singleton
• Prototype
• Fabrique (Factory)
• Fabrique Abstraite (Abstract Factory)
• Monteur (Builder)

Le patron de structure (Structural Pattern)

Structurer les classes et objets afin de garder ceux-ci flexibles et efficaces au travers de leur structuration et leur interface.

Quelques exemples:

• Pont (Bridge)
• Façade
• Adaptateur (Adapter)
• Objet composite
• Proxy
• Poids-mouche (Flyweight pattern)
• Décorateur (Decorator)

Le patron de comportement (Behavioral Pattern)

Permet de modéliser et répartir les responsabilités entre les objets.

Quelques exemples:

• Chaîne de responsabilité (Chain of Responsibility)
• Commande (Command)
• Interpréteur (Interpreter)
• Itérateur (Iterator)
• Médiateur (Mediator)
• Mémento
• Observateur (Observer)
• Etat (State)
• Stratégie (Strategy)
• Patron de méthode (Template Method Pattern)
• Visiteur (Visitor)

Quand et pourquoi les utiliser ?

Un développeur ayant une culture du Design Pattern (et sachant quand c’est le moment d’en utiliser un) pourra trouver plus rapidement une solution grâce aux différents paradigmes proposés et ayant déjà fait leurs preuves.

Il permet donc :

• d’accélérer le processus de développement,
• de réduire les bugs potentiels,
• de connaître les bonnes pratiques et les pièges à éviter
• de s’appuyer sur la capitalisation de l’expérience de la communauté.

Il est donc vraiment important de l’intégrer le plus tôt possible dans le processus de conception / développement.
Un bon développeur devra savoir s’arrêter et remettre en question son code lorsqu’il se retrouve face à un problème.
Il faudra se demander “Ne suis-je pas en train de réinventer la roue ? N’existe t’il pas un patron qui pourrait répondre à ma problématique ?”

Quelques exemples

Il existe de nombreux modèles qui sont souvent très utilisés. La plupart du temps beaucoup de développeurs en utilisent sans savoir qu’il s’agit de modèles de patrons de conception. Voici quelques cas parmis ceux que vous utilisez peut-être sans même le savoir.

Le Modèle Composite : pour représenter des structures arborescentes pour présenter des hiérarchies de composants / composés.

Le Singleton qui permet de limiter l’instanciation d’une classe à un seul objet.

Les itérateurs qui permettent de parcourir les éléments d’une collection (liste, arbre etc.).

Le Proxy : substitue une classe à une autre en utilisant la même interface permettant entre autres la sécurité ou l’appel de méthodes à distance.

Le Décorateur : attacher dynamiquement des nouvelles responsabilités à un objet

Le Façade pour simplifier l’utilisation d’une interface complète.

L’Observateur : mécanisme de souscription afin d’envoyer des notifications à plusieurs objets qui sont observés.

Le Stratégie qui permet de créer des algorithmes séparés dans plusieurs classes autonomes / interchangeables.

Voici un cas d’usage écrit en Typescript pour savoir quand l’utiliser. Imaginons que l’on souhaite faire plusieurs actions différentes mais avec le même objet, nous pourrions être tenté de faire une classe qui contiendrait toutes ces actions? Oui et non, car celà reviendrait à ne pas respecter un des principes du SOLID à savoir le “S” pour Single Responsibility Principe. Prenons le cas d’un site, nous voulons développer une classe qui permet de gérer le paiement.

Interface PaymentStrategy {
    public doPay(amount: number): void;
}

nous allons ensuite créer plusieurs classes correspondant aux différents moyens de paiement :

class CreditCardStrategy implements PaymentStrategy {

    //  ici on fait des traitements différents

    public doPay(total: number): void {
        console.log('je paye en carte de crédit un total de', total);
    }		
}

class OtherPaymentStrategy implements PaymentStrategy {

    //  ici on fait des traitements différents

    public doPay(total: number): void {
        console.log('je paye en X moyen de paiement un total de', total);
    }		
}

class Cart {

    private total: number;

    constructor(total: number){
        this.total = total;
    }
    
    public getTotalCart(): number {
        return this.total;
    }

    public doPay(PaymentStrategyMethod methodToPay): void {
        methodToPay.doPay(this.getTotalCart());
    }
}

exemple :

cart = new Cart(199);
cart.doPay(new CreditCardStrategy()); // pour le premier cas
cart.doPay(new OtherPaymentStrategy()); // pour le second cas

La Fabrique pour instancier des objets dans une classe mère tout en laissant aux sous classes le choix des types d’objets à créer.

L’ Object Pool pour économiser le temps d’instanciation et de suppression lorsque de nombreux objets ayant une vie courte seront utilisés.

Pour finir

Vous l’aurez compris, le Design Pattern fait partie intégrante des outils indispensables du développeur.
Le but de cet article est de vous donner l’envie de vous y intéresser, de lire, de découvrir et surtout d’apprendre à savoir quand les utiliser afin de répondre au mieux à vos besoins.

Attention toutefois à ne pas tomber dans l’exact contraire, à savoir, l’anti pattern.
Cela reviendrait à faire le mauvais choix et donc à apporter la mauvaise réponse à une problématique donnée.

Voici un exemple développé en Java par Maxime, il combine le Pattern Observer et Builder avec comme thème l’organisation de course à pied.

Lien du repo git : https://github.com/ekit3/design-pattern

Sources ayant servie à écrire l’article et pour aller plus loin :

https://fr.wikibooks.org/wiki/Patrons_de_conception https://ryax.tech/fr/design-pattern-cest-quoi-et-pourquoi-lutiliser/ https://refactoring.guru/ https://madasamy.medium.com/introduction-to-object-oriented-design-patterns-part-i-4e5c7845015b

Voyez la page finale comme un puzzle où chaque morceau serait un composant MFE. Ces composants peuvent être une barre de navigation, un bouton ou tout simplement un texte. Cette découpe apporte en quelque sorte de la “liberté”.
Ce type d’architecture permet de choisir son framework Front, d’être autonome sur sa livraison et de séparer les projets par équipes au lieu de travailler sur un monolith commun. Le but du MFE est de simplifier la gestion, la maintenabilité, la conception et le découpage des interfaces utilisateurs.
Garantir le bon fonctionnement de la page Web finale demandera de la rigueur et un travail commun.
Il existe une multitude de façon de faire du micro-front end notamment en utilisant des technologies HTML (Iframe) ou un agrégateur en Back End (type Node Js, Java etc..)…

Origine

Le terme est apparu dans les RADAR techniques de Thoughtworks en 2016 mais c’est en 2019 que les micro-front end commencent à émerger.

Thoughtworks : qui sont-ils ?

C’est un organisme public qui se concentre sur la mise en place de concept technologique.
Ils mettent à disposition la conception et participe à la livraison de logiciels, d’outils, ils proposent également un service de conseil informatique.

Que s’est-il passé entre l’apparition du terme et sa réelle émergence ?

Thoughtworks a mis à disposition une recherche réalisée dans leurs équipes. Cette recherche porte sur la mise en place des micro-services au niveau de l’UI. Thoughtworks a partagé l’évolution conceptuelle des micro-front end. En Novembre 2016, arrivent les premières idées à propos de ce type d’architecture (des idées mais aussi des POC et des phases d’évaluation).

Les ingénieurs de Thoughtworks pensent qu’il serait intéressant d’appliquer un système de micro-services au niveau de l’UI afin d’éviter les monolithes. Ils mettent en avant le fait que l’approche BFF (back-for-front : couche permettant la communication entre le back-end et le front-end) en serait largement bénéficiaire.

S’ensuit une communication en Mai 2018 (lors de la phase d’essai), celle-ci nous informe que des équipes ont mis en place des structures monolithiques au niveau des services back. Ils font un petit rappel afin d’expliquer l’objectif des micro-front end : obtenir des composants/pages isolés et indépendants les uns des autres et qui appartiennent à différentes équipes.

En Avril 2019 débute la phase d’émergence, à ce stade, Thoughtworks pense que la mise en place des micro-front end représente un bénéfice certain pour les équipes de développement. A partir de ce moment ils commencent à informer et à conseiller sur les implémentations liées aux micro-front end.

“Et si j’ai rien compris ?”: Petit Résumé

Le processus lié à ce concept, dans un format de type release/actualisation semble venir de la frustration de certaines équipes vis-à-vis des monolithes.

Les “assessments” donne pour définition des structures monolithiques Front : « large and sprawling browser applications that are as difficult to maintain and evolve as the monolithic server-side applications we’ve abandoned »

Soit en français : « Des applications “navigateurs” volumineuses et entremêlées étant aussi difficiles à maintenir et à faire évoluer que des applications back monolithiques déjà abandonnées. »

Mise en place

– La Gouvernance

La gouvernance est un élément indispensable lors de l’initialisation d’un projet micro-front end. La liberté provenant de ce type d’architecture est à double tranchant. Une plus grande liberté permet de réaliser plus facilement un ensemble de tâches mais c’est aussi un moyen de surcharger votre application.

Voici 3 axes de réflexions afin de mieux comprendre la problématique :

– Le premier : déterminer le scope

Réfléchissez à la taille de vos composants (comme ce qui est fait pour les briques dans un modèle microservice en back-end). Cela permet ainsi de réfléchir à la taille de vos équipes et le nombre de ressources à mobiliser. (Votre budget vous remerciera.)

– Le second : il en faut un pour les gouverner tous.

L’indépendance des composants peut faire perdre de vue l’objectif commun: la réalisation d’une interface graphique pour une application. Cette application a des attentes en termes d’objectifs, de performances, ou encore d’image (marketing etc…).
Il faut, par exemple, veiller à avoir une équipe responsable du partage de la connaissance et de la culture afin de ne pas diviser “pour mieux régner” mais plutôt de “réunir pour mieux réussir”. Il est également important d’imaginer la mise en place de tests d’intégrations globaux au niveau du plus haut parent de la famille des composants.
(Imaginez une application dont chaque composant possède sa propre charte graphique façon sapin de noël..)

Une solution commune dite “Core” se matérialise par une équipe gérant le noyau du site, elle régit les librairies de bases, la création, la gestion des outils (e.g.. Eventbus), la charte graphique etc.
Les composants “enfants” hériteront de tout ce qui aura été prévu et partagé par le noyau applicatif.

– La troisième : comment bien s’équiper pour la performance ?

Il faut distinguer deux aspects lorsque l’on pense à la qualité des MFE : la performance de chacun d’entre eux mais également du site global en termes d’affichage et de rendu. Avoir de multiples composants, c’est accepter d’avoir un possible laps de temps au moment de la création/initialisation de chacun.
Il faut également penser au démarrage et à l’intégration de nouveaux MFE dans l’architecture globale, que ce soit en termes de cohérence, de qualité de code, de sécurité, de chaîne d’intégration et de déploiement.
Pour éviter cela, il faut mettre en relation des experts techniques (architectes, leader, etc.) capables de trouver des solutions performantes et de partager les bonnes pratiques à tous ces différents niveaux.

Point d’attention : le runtime
Plus il y a de frameworks, plus il y aura de runtimes et donc plus de risques que le poids de la page soit augmenté et sa performance dégradée.
Il faudra limiter la diversité des frameworks utilisés.

Ce graphique montre la consommation en runtime pour chaque build avec le runtime Svelte. On dénote qu’avec à peine 10 composants on consomme moins qu’un Angular pour ne citer que lui.

Que doit-on retenir ?

Pour résumer en un seul mot : “Communiquez !”
L’indépendance apportée par les MFE peut desservir, chaque équipe faisant ses composants de manière “isolée”, si personne ne s’assure de la cohérence globale cela peut rapidement devenir néfaste.
Sans communication et gouvernance, la page finale peut vite se retrouver alourdie (du au fait d’un ensemble de technologies mélangées et de la multiplicité des frameworks utilisés) ou chartée de façon bien différente et donc perdre de la cohérence (notamment via le design).
Tous ces risques peuvent vite amener à regretter les monolithes.

Schéma d’archi

Voici un exemple qui schématise une architecture micro front avec trois MFE. Chaque composant est développé avec une techno différente (Vue, Angular, React) et géré par une équipe spécifique, possédant ses outils de CI/CD, de tests, etc.

Framework, technos et outils

Une pluralité de frameworks qui vont vous faciliter le développement des micro frontend est disponible : chacun a sa propre philosophie dans la manière d’aborder les concepts liés aux micro frontend.
Parmi les plus connus on peut citer Single-spa, Bit, Qiankun, Open components …

Pros/Cons

De grandes entreprises ont choisi de se lancer dans les micro frontend, comme IKEA sur son magasin en ligne, Spotify avec son application desktop ou encore Leroy Merlin avec son site Web et Kobi.

Pour chacune de ces applications, des bénéfices se sont rapidement fait sentir, par exemple à travers leur vie dans les différentes plateformes, à travers l’expérience de l’utilisateur ou encore sur une meilleure réalisation des développements grâce à des équipes plus réduite mais concentrées sur une seule feature.

Les avantages et inconvénients des MFE sont fortement liés.

Le découpage du code

• Pros : plus simple, plus léger, c’est un vrai bonus de lisibilité et de maintenabilité.
• Cons : même si la compréhension unitaire des composants est plus simple, la complexité globale de l’application peut en revanche être plus floue.

La liberté des choix technologiques

• Pros : plus de technologies disponibles implique plus de possibilités.
• Cons : cela peut induire des problèmes de performances, de compatibilité voire de maintenabilité.

L’indépendance et l’autonomie des équipes

• Pros : cet aspect améliore les conditions et la qualité de développement.
• Cons : la relation inter-équipes ne doit pas être négligée. Le risque étant de s’éloigner de l’objectif principal, d’avoir des demandes de refontes (e.g : ne correspond pas à l’attente des composants consommateurs) et même des migrations d’outils.

L’indépendance des livraisons

• Pros : le choix des outils d’intégration et de déploiement continue est possible. Cela permet de livrer uniquement certaines parties de l’application.
• Cons : mais cela implique une gestion de la qualité, du release management ou software delivery global plus complexe à mettre en place.

Il est nécessaire de mettre en place une gouvernance forte pour garantir une cohérence dans les choix pris lors du développement des différents composants. (Objectif : assurer une qualité et maintenabilité globale).

Links : https://www.infoq.com/news/2019/04/real-world-framework-benchmark/