En tant que développeur, nous cherchons souvent des moyens d’améliorer nos applications. Les rendre plus robustes, plus normées, ou encore anéantir les potentiels effets de bord. La montée des langages fonctionnels a pu faire réapparaître certains concepts mathématiques pour améliorer tout ça. C’est le cas des types abstraits (en anglais, abstract data type ou ADT). Au-delà des gains cités, certains ADT permettent d’améliorer la gestion de certains langages.

L’illustre Henri, qui aime tant les mathématiques, semble être très intéressé par le sujet, mais surtout parce qu’il existe un ADT pour optimiser son application du plus fort cailloux. Cela permettra d’illustrer les explications qui suivent.

Définitions

Pour créer un type de donnée il faut réunir un ensemble de valeurs et des opérations à appliquer sur cet ensemble. On peut prendre exemple sur les nombres entiers (int, integer). Il est possible d’appliquer une multitude d’opérations sur les entiers : additions, soustractions, multiplications, etc.

Une des analogies les plus reprises en informatique des types de données sont les primitives, comme les entiers, les booléens, ou les float par exemple. N.B : Les types primitifs sont nativement gérés par le langage, qui stocke directement les valeurs des variables en mémoire, parfois dans une zone mémoire dédiée (la stack).

L’évolution d’un type de donnée, ce sont les types de données définis par utilisateur. Pour vulgariser il s’agit d’une structure nommée et composée de type de données. Il est possible de les représenter par des structures, des énumérations ou encore des unions. Pour illustrer la représentation d’un point est un type de données définies par utilisateur : Point(int x, int y).

Les types de données défini par utilisateur ne sont pas définis par la machine contrairement aux primitives. Les opérations sous-jacentes de ce type de données sont elles aussi définies par l’utilisateur (le développeur).

Un type abstrait peut être représenté comme le moule d’un type de données définis par utilisateur à la différence près que ce type doit amener une certaine robustesse dans l’écriture de types. Ce type de données doit répondre à trois contraintes pour subsister dans un système de type. Il doit être capable de définir des types sommes, produits et récursifs.

Pré-requis du système de type pour faire des ADT

1 – Le type somme (tagged-union, variant) c’est la capacité de définir un type pouvant se définir par un sous-ensemble fini de types. En Java cela correspond aux sealed-interface, en OCaml ce sont les variants, en Rust les enum. Exemple en OCaml :

type month_type = 
  | PLEIN 
  | CREUX 
  | BIS of int

2 – Le type produit (record) correspond à la capacité de créer des structures dans un langage. En Java, on peut créer des objets ou des records, en Rust ou en C on peut créer des structures (struct).

3 – Le type récursif correspond à la capacité pour un type de s’appeler lui-même. Exemple avec les variants :

 type List = 
  | Item of int * List
  | Empty

Item (1, Item (2, Item ( 3, Empty)))

• Caml
• Rust
• Haskell
• Java 17+
• Typescript
• Python
• Scala
• Kotlin

Cas d’utilisations

Les types de données abstraits permettent d’acquérir de la robustesse applicative ET conceptuelle. Cela permet également de pouvoir créer des design pattern purs et de simplifier la mise en place de machine à état. Enfin les ADT permettent de rapprocher les données d’un programme lié aux structures algébriques.

Voici une liste de quelques types abstraits connus, liés aux structures algébriques:

• La présence de valeur (Option)
• La réussite d’un programme (Try)
• La réussite ou l’erreur d’un programme (Result)
• La possibilité d’afficher une donnée (Show)

Henri a préparé quelques cartes que vous pourrez trouver ici !

La parole à Henri

Henri nous rappelle que son application a été codée en Java 17. La gestion d’erreur dans certains langages peut-être très gourmande en termes de ressources. Ce lien explique en détails le bytecode derrière un try-catch. Pour résumer, lorsqu’une exception survient il faut pouvoir dire à la machine de revenir en arrière et exécuter le code dans la partie “catch”. Plusieurs années se sont écoulées depuis et Henri trouve que son application est obsolète Il demande à son ami de faire évoluer son application, mais se retrouve depuis quelques temps confronté à une multitude de problème qu’il ne comprend pas :

java.lang.IllegalArgumentException: D20160229 is not a Caillou

Henri est venu nous voir en nous expliquant qu’il a ce problème à chaque fois qu’il enregistre un de ses cailloux un 29 février. Cela fait déjà 6 ans qu’Henri n’arrive pas à enregistrer son caillou préféré. Prenons notes de l’existant :

• Les fonctionnalités sont rétro-compatibles avec l’ancien modèle.
• La structure de données d’un caillou a changé comme suit :
  • Un caractère et 8 chiffres. Nous décidons de corriger l’ensemble tel qu’il soit constitué d’un caractère et d’une date au format yyyyMMdd. (Cela corrigera en parti les problèmes de la nouvelle application d’Henri) Nous ne pouvons donc plus nous fier à l’ensemble CPH (Cailloux Potentiels d’Henri), nous sommes sur un ensemble différent que nous nommerons NCPH (Nouveaux Cailloux Potentiels d’Henri) . Notons que cet ensemble est composé de l’ensemble CPH et de toute chaîne de caractères avec les caractéristiques susmentionnées (nommons cet ensemble CPGH pour Cailloux Potentiels du Grand Henri). On obtient donc CPGH = CPH + NPCH.

Malgré notre précédente correction Henri nous a remonté qu’il subsiste quelques lenteurs et nous fait part de ses besoins :
1 – Il veut pouvoir basculer sur son ancien modèle à tout moment.
2 – Faire en sorte que son application ne subisse plus de lenteurs / erreurs incompréhensibles.
Pour le premier point nous verrons une prochaine fois l’application de la théorie des catégories (plus particulièrement la flèche). Pour le second ça tombe bien, car nous avons investigué et sommes tombé sur quelques imbrications de try-catch dignes d’une bonne programmation défensive. Cela s’explique par le fait de devoir convertir les éléments de CPH vers CPGH. /!\ N’oublions pas qu’Henri procède à des millions d’enregistrements de cailloux par jour.

La solution au problème 

static Result<Caillou, Exception> create(String name){
    var letter = name.charAt(0);
    if(letter < 65 || letter > 90) {
        throw new IllegalArgumentException(format("%s is not a Cailloux", name));
    }

    var dayOfYear = Integer.parseInt(name.substring(1));
    if(dayOfYear < 0 || dayOfYear > 365) {
        throw new IllegalArgumentException(format("%s is not a Cailloux", name));
    }

    return new Caillou(letter, dayOfYear);
}

void handleCreate(String input){
    try {
        var result = create(input);
        doSomethingWithCaillou(result);
    }catch(Exception error){
    log(error);
    }
}

(L’ancien code.)

Ces imbrications nous privent de précieuses performances. Une des solutions à ce problème c’est l’ADT Result. Malheureusement pour Henri en Java 17 il n’existe pas d’implémentation de Result. Cependant il y a eu une grande avancée permettant de créer ce genre de typage :

• Les interfaces scellées
• Les records
• Le switch-pattern-matching Voici comment on pourrait représenter le Result en Java 17

sealed interface Result<T,E> permits Result.Ok, Result.Err {
    record Ok<T,E>(T ok) implements Result<T,E> {
        public Ok {
            java.util.Objects.requireNonNull(ok);
        }
    } 
    record Err<T,E>(E error) implements Result<T,E> {
        public Err {
            java.util.Objects.requireNonNull(error);
        }
    }
    public static<T> Ok ok(T ok){
        return new Ok(ok);
    }
    public static<E> Err err(E error){
        return new Err(error);
    }
}

Voici comment Henri l’utilise aujourd’hui :

static Result<Caillou, Exception> create(String name){
    var letter = name.charAt(0);
    if(letter < 65 || letter > 90) {
        return Result.err(new IllegalArgumentException(format("%s is not a Cailloux", name)));
    }

    var dayOfYear = Integer.parseInt(name.substring(1));
    if(dayOfYear < 0 || dayOfYear > 365) {
        return Result.err(new IllegalArgumentException(format("%s is not a Cailloux", name)));
    }

    return Result.ok(new Caillou(letter, dayOfYear));
}

void handleCreate(String input){
    switch (create(input)){
        case Result.Err<Caillou, Exception> result -> log(result.error);
        case Result.Ok<Caillou, Exception> result -> doSomethingWithCaillou(result.ok);
    }
}

(Le nouveau code)

Maintenant Henri est heureux, il propose pour conclure quelques cartes pour mémoriser certains ADT et leurs particularités.

Sources

• https://en.wikipedia.org/wiki/Tagged_union
• https://fr.wikipedia.org/wiki/Structure_de_donn%C3%A9es
• https://fr.wikipedia.org/wiki/Type_abstrait
• https://dev.realworldocaml.org/variants.html
• https://jpintelli.com/2020/12/28/adt-with-java-sealed-classes-pattern-matching-records/
• https://en.wikipedia.org/wiki/Record_(computer_science)
• https://fr.wikipedia.org/wiki/Type_r%C3%A9cursif
• https://blog.shangjiaming.com/vavr-introduction/
• https://www.vavr.io/
• https://v2.ocaml.org/manual/gadts-tutorial.html
• https://cs.wellesley.edu/~cs251/s12/handouts/modules.pdf
• https://medium.com/@aoturan/commonly-used-abstract-data-types-d9470b14f864

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

Le tout premier algorithme connu a été écrit en -300 avant notre ère par Euclide (PGCD).
Aujourd’hui les mathématiques font rêver, font peur et semblent parfois inaccessibles. Une chose est sûre, elles sont partout.
Comptables, développeurs, boulangers ou même politiques, tous utilisent les mathématiques : le langage suit un ensemble de règles mathématiques.
Les structures du langage sont réalisées par l’application d’un arbre de la syntaxe abstraite.

Les structures algébriques font partie des bases des mathématiques. C’est un socle sur lequel de nombreuses règles sont construites.
En particulier, pour réaliser des applications robustes, performantes et maintenables. Elles peuvent apporter une aide précieuse.

Définition

Les structures algébriques sont un ensemble d’entités basées sur des axiomes initiaux à partir desquels il est possible de démontrer un certain nombre de lois.
L’objectif de ces structures est d’assurer, après avoir vérifié des axiomes simples, la déduction de lois dont il est possible de tirer des conclusions utiles.
Les premières structures à étudier, les plus simples, sont les magmas et les monoïdes.

Les magmas

Les magmas sont les fondations des structures algébriques, le premier niveau. Ils permettent de définir le contexte.
Cependant, n’ayant que très peu de contraintes, ils ne donnent pas la possibilité d’en déduire beaucoup de lois.

Recette miracle:
Pour créer un magma, il faut réunir un ensemble et une loi de composition interne.

Un ensemble est constitué d’éléments en nombre fini ou non et peut être constitué de différents types d’éléments.
Par exemple, l’univers est un ensemble contenant des sous-ensembles de planètes, d’étoiles, de trou noirs, etc.

Une loi de composition interne est une opération entre deux éléments de l’ensemble qui renvoie un élément de ce même ensemble.
L’opération consistant à mélanger deux pots de peinture crée un autre pot de peinture avec une couleur potentiellement différente.

CH	 	 	 	 
C056	B084	M083	C189	M356

Henri a 8 ans, adore les cailloux et ses amis (Charles, Bertrand et Marie), il est aussi un spécialiste des mathématiques.

Henri possède 5 cailloux et une manière très spéciale de les nommer. Cependant Henri ne donne pas de noms aléatoires. Ses cailloux ont un nom relatif à l’endroit et au jour où ils les trouvent.
Par exemple Henri a trouvé C056 dans le jardin de son ami Charles, le 56ème jour de l’année.

CH est un sous-ensemble d’un ensemble. Il est caractérisé par la concaténation d’une lettre et d’une série de chiffres allant de 000 à 365 ; appelons cet ensemble CPH (Cailloux potentiels d’Henri).

Henri est confronté à un problème, il veut savoir quel est son caillou le plus fort. Il va donc pour cela créer une opération pour lui permettre de s’y retrouver.

Voici en quoi consiste son opération (selon ses propres mots) :

1. Calculer le poids de chaque caillou.
2. Multiplier la position dans l’alphabet de la lettre par le numéro du jour de l’année. Comparer lequel est le plus gros, si les deux sont égalités le poids de la lettre l’emporte.

Le résultat de l’opération d’Henri a créé ce tableau :

Henri ne le sait pas mais il vient de créer un Magma sur l’ensemble CH.

L’application du plus fort Caillou v0.1.0

Configuration requise:
Un magma, ne possédant aucune autre propriété que celles susmentionnées, permet deux choses essentielles.

1. Contrôler les limites des entrées
2. Mettre en pratique une analyse séquentielle via une opération (LCI).

Classiquement (sans savoir que c’est un magma) une simple analyse syntaxique sur une chaîne de caractère suffit :

public static String stronger(List<String> cailloux){
    var inputFormat = "[A-Z]([0-2][0-9][0-9]|3([0-5][0-9]|6[0-5]))";
    ToIntFunction<String> letter = word -> word.charAt(0) - 64;
    String result = null;
    for(var aCaillou : cailloux){
        if(!aCaillou.matches(inputFormat)){
            throw new IllegalArgumentException("is not a Caillou");
        }
        if(result == null || result.trim().isEmpty()){
            result = aCaillou;
            continue;
        }
       var weightResult = (result.charAt(0) - 64) * Integer.parseInt(result.substring(1));
         var weightACaillou = (aCaillou.charAt(0) - 64) * Integer.parseInt(aCaillou.substring(1));

        if(weightResult < weightACaillou
            || (weightACaillou == weightResult &&
                letter.applyAsInt(result) < letter.applyAsInt(aCaillou))
        ){
            result = aCaillou;
        }
    }
    return result;
}

Ici les cailloux potentiels d’Henri ont une forme très spécifique. Voici le résultat avec un magma :

record Caillou(
        char letter,
        int dayOfYear
) {
    Caillou{
        if (dayOfYear < 0 || dayOfYear > 365)
            throw new IllegalArgumentException("is not a Caillou");
        if (letter < 65 || letter > 90)
            throw new IllegalArgumentException("is not a Caillou");
    }

    int weight() {
        return ((letter - 64) * dayOfYear);
    }

    Caillou strongest(Caillou other){
        if(other.weight() > this.weight()
            || (other.weight() == this.weight()
                && other.letter > this.letter)) {
            return other;
        }
        return this;
    }

    public static Caillou stronger(Caillou a, Caillou b){
        return a.strongest(b);
    }

    public static Caillou of(String name){
        return new Caillou(name.charAt(0), Integer.parseInt(name.substring(1)));
    }
}
Optional<Caillou> henrisCaillou(List<String> inputList){
  return inputList
    .stream()
    .map(Caillou::of)
    .reduce(Caillou::stronger);
}

Le magma permet de définir le cadre de travail :

• Connaître l’ensemble des éléments sur lesquels les actions sont réalisées.
• Connaître l’opération qui sera utilisée en s’assurant que le résultat fait partie de l’ensemble Aucune autre conclusion ne peut être déduite de ce cadre de travail. Il s’agit de structurer la pensée mais pour aller plus loin et faciliter les traitements, il est nécessaire de définir un cadre légèrement plus contraint.

Aucune autre conclusion ne peut être déduite de ce cadre de travail. Il s’agit de structurer la pensée mais pour aller plus loin et faciliter les traitements, il est nécessaire de définir un cadre légèrement plus contraint.

Les monoïdes

Les monoïdes proviennent d’un terme allemand, mal-traduit, signifiant “Individu”.
Les monoïdes sont, comme toutes les structures algébriques, des magmas respectant des axiomes supplémentaires. Ces axiomes permettent de démontrer des propriétés qui peuvent s’avérer très utiles.

Recette miracle Pour créer un monoïde nous avons besoin d’un magma unifère et associatif.

Unifère signifie que l’ensemble contient un élément neutre vis-à-vis de l’opération du magma. Cet élément neutre n’impacte pas le résultat si on réalise l’opération avec n’importe quel élément. (n+0 = n et 0+m = m; 0 est un élément neutre pour l’opération '+' dans l’ensemble des entiers).
Associatif signifie qu’une chaîne d’opération peut être réalisée dans n’importe quel ordre sans que le résultat s’en trouve modifié. (a+b+c = (a+b)+c = a+(b+c); la somme est associative).

Associatif signifie qu’une chaîne d’opération peut être réalisée dans n’importe quel ordre sans que le résultat s’en trouve modifié. (a+b+c = (a+b)+c = a+(b+c); la somme est associative).

Ces deux propriétés du monoïde permettent de démontrer une loi très intéressante pour les traitements informatiques : les calculs parallèles. Sans faire la démonstration, un exemple permet de s’imaginer cette propriété en utilisant le monoïde précédemment utilisé : l’ensemble des entiers munis de la somme.

L’opération consiste à réaliser 1+2+3+4+5+6. L’associativité permet de réaliser les opérations sous la forme (1+2)+(3+4)+(5+6) = 3+7+11 = 10+11 = 21. Pour réaliser les cinq opérations (nombre de signes ‘+’), trois séries de calculs ont été nécessaires (nombre de '=') en parallélisant trois opérations dans la première étape. Cela est mathématiquement permis uniquement dans le cadre du monoïde.

Exemple : Le Monoïde derrière le Magma d’Henri

Précédemment, Henri a créé un magma, il a également créé un monoïde sur l’ensemble CPH (Cailloux potentiels d’Henri). Comment Henri a réussi à construire ce monoïde ?

Associativité Il faut démontrer l’associativité de l’opération stronger(), visuellement sur l’ensemble CH on peut le voir (effet miroir) :

Il s’agit d’appliquer ces vérifications sur l’ensemble CPH. En mathématiques il est coutûme de démontrer par formulation que tout élément respecte l’associativité. Naïvement c’est possible (un élément à la fois). Cet ensemble est présent dans 2 autres ensembles : L’alphabet et les chiffres allant de 0 à 365.

Il est possible de décomposer et se placer dans un ensemble commun :

Il existe une étape intermédiaire : le calcul du poids. Le calcul du poids est un entiers allant de 0 à 9 125 (25 (Z) * 365) . Nous appliquons ensuite une comparaison au maximum. Cette étape intermédiaire se place dans un sous-ensemble d’un ensemble très connu : les entiers naturels contenant 0. De plus, l’associativité des extremums (calcul maximum et minimum) a été démontrée sur cet ensemble.

Unifère

Il faut prouver l’existence d’ un élément neutre. Selon les critères d’Henri le poids d’un cailloux est relatif à sa position dans l’alphabet puis agrégé au jour de l’année où Henri l’a trouvé (sauf exception en cas d’égalité : la lettre l’emporte). Cela veut dire que le poids minimum qui est de 0 (représenté par le cailloux potentiel d’Henri A000) est le cailloux le plus faible possible dans cet ensemble. 0 étant le nombre le plus petit des entiers naturels contenant 0, cela fait de lui un élément neutre dans le calcul du maximum :

• Pour tout x dans N; tel que x >= 0 alors x.

Le classement est ingénieux, à quoi peuvent servir ces axiomes ?

L’associativité permet de dire que peu importe le sens d’une opération elle aura le même résultat. Si on l’applique en première ou en dernière, rien ne change !
L’élément neutre permet de mettre en place une forme d’initialisation pour le cas où un jour Henri oublie de mettre le nom de tous ses cailloux dans son application par exemple.

Henri aimerait vraiment que son application soit plus performante car il en a encore une centaine…. de milliers de cailloux à traiter.

L’application du plus fort Caillou v0.1.1

L’associativité permet de mettre en place du multi-threading.
L’élément neutre a un rôle d’initialisation/valeur par défaut.

Classiquement la mise en place d’une certaine parallélisation est enclin à de nombreux doutes. Pour continuer l’exemple, il faut mettre ces doutes de côté.

public static String stronger(List<String> cailloux){
    var inputFormat = "[A-Z]([0-2][0-9][0-9]|3([0-5][0-9]|6[0-5]))";
    ToIntFunction<String> letter = word -> word.charAt(0) - 64;
    AtomicReference<String> atomicResult = new AtomicReference<>("A000");
    var pool = new ForkJoinPool();

    for(var aCaillou : cailloux) {
        pool.execute(() -> {
            if(!aCaillou.matches(inputFormat)){
                throw new IllegalArgumentException("is not a Caillou");
            }
            var result = atomicResult.get();
            var weightResult = (result.charAt(0) - 64) * Integer.parseInt(result.substring(1));
            var weightACaillou = (aCaillou.charAt(0) - 64) * Integer.parseInt(aCaillou.substring(1));

            if(weightResult < weightACaillou
                    || (weightACaillou == weightResult &&
                    letter.applyAsInt(result) < letter.applyAsInt(aCaillou))
            ){
                atomicResult.set(aCaillou);
            }
        });
    }
    return atomicResult.get();
}

Result : Y364
Time: 78 ms over 250000 iterations ; CPU usage (%): 4.438960808734625 %

Avant : Y364
Time: 235 ms over 250000 iterations ; CPU usage (%): 4.438960808734625 %

Voici le résultat avec la réflexion sur les monoïdes :

record Caillou :
….
public static Caillou neutral(){
    return new Caillou('A', 0);
}
….
Optional<Caillou> henrisCailloux(List<String> inputList){
  return inputList
    .parallelStream()
    .map(Caillou::of)
    .reduce(Caillou.neutral(), Caillou::stronger);
}

Result: Optional[Caillou[letter=Y, dayOfYear=364]]
Time: 8 ms over 250000 iterations ; CPU usage (%): 4.438960808734625 %

Avant : Optional[Caillou[letter=Y, dayOfYear=364]]
Time: 12 ms over 250000 iterations ; CPU usage (%): 4.438960808734625 %

Le monoïde permet d’apporter de nouvelles propriétés utiles pour une meilleure conception :

• Une chaîne d’opération peut être parallélisée en garantissant le résultat
• Une valeur par défaut peut être utilisée pour éviter les erreurs de traitement Cette structure est la première à apporter des propriétés utiles aux conceptions en informatique. Il en existe beaucoup d’autres, plus ou moins complexes à identifier, pour obtenir divers avantages. Ainsi, en vérifiant des propriétés sur un ensemble et une opération, il est possible de déduire de nombreuses lois qui facilitent ou optimisent les traitements.

Ce qu’on doit en retenir

Bien sûr il ne faut pas forcément coder comme un grand mathématicien avec son tableau rempli de formule (quoique en dehors des formules ?).
Comme l’a dit un grand sage “apprendre à coder via des structures et seulement des structures est un comportement élitiste”.
Ce même grand sage a dit qu’il est préférable d’apprendre à les identifier.
Identifier leurs forces, leurs faiblesses, le contexte le plus adéquat à leur utilisation. Une fois qu’on arrive à les cerner, une porte s’ouvre vers une autre manière de développer des applications qualitatives.
La multitude de structures algébriques qui existent n’est pas exposée ici. Nous vous avons fait vivre les aventures d’Henri pour ouvrir une perspective sur ce monde et dans l’espoir que vous puissiez vous y faire votre propre avis.
Sans les mathématiques, tout est faisable, mais avec les mathématiques, tout est structuré.

Sources

• https://blog.derniercri.io/observons-une-premiere-structure-algebrique-appliquee-a-linformatique-le-monoide/
• https://fr.wikipedia.org/wiki/Th%C3%A9orie_des_cat%C3%A9gories#Morphismes – Xavier Van de Woestyne
• Thomas Haesslé – Cours et discussions (https://oteku.github.io/)
• Lambda Lille – conférences (https://twitter.com/lambdalille)
• https://www.youtube.com/watch?v=RaqlxOihGxw&list=PLNefH6S6myiMFlgsEIGHb8KZaLKE2eAZQ – micmaths
• https://fr.wikipedia.org/wiki/Th%C3%A9orie_des_cat%C3%A9gories#Morphismes
• https://fr.wikipedia.org/wiki/Structure_alg%C3%A9brique

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/