Qu'est-ce que le modèle de composant WebAssembly ?
WebAssembly, ou Wasm en abrégé, a prouvé à maintes reprises qu'il s'agissait d'une technologie révolutionnaire, grâce à sa vitesse d'exécution rapide et quasi native, à sa variété de choix de langages de programmation et à son modèle robuste de sandboxing de refus par défaut. Il a déjà été largement utilisé sur le Web et a également été un acteur redoutable côté serveur.
Chaque écosystème en plein essor a besoin d'une vision de la manière dont toutes les pièces s'assemblent, et c'est exactement là qu'intervient le modèle de composants WebAssembly . Le modèle de composant est un système qui facilite les interactions entre les unités individuelles de code WebAssembly et les interactions entre le code WebAssembly et un environnement hôte. Tout est centré autour du concept de composants WebAssembly, qui sont essentiellement des modules Wasm classiques avec des types de données codés. Ces types permettent la génération de code de liaison en coulisses qui permet aux composants de communiquer de manière transparente entre eux.
Le modèle de composants inaugure une nouvelle ère de développement logiciel moderne : les développeurs peuvent sélectionner des composants dans n'importe quel écosystème de langage de programmation et les composer dans une seule application. Vous avez une application de traitement de données en Python mais vous avez besoin d'un analyseur efficace en Rust ? Aucun problème. Une équipe de votre organisation maîtrise Go, mais une autre n'écrit qu'en JavaScript ? Aucun problème : chaque équipe peut produire des composants WebAssembly qui se composent sans problème.
Pourquoi nous en avons besoin, techniquement
WebAssembly est confronté à un problème que nous avons observé avec presque toutes les nouvelles plateformes d’exécution de code : comment partager de manière sûre, sécurisée et efficace des données entre des unités de code distinctes, potentiellement produites par des chaînes d’outils de langage de programmation complètement différentes ? En général, deux modules WebAssembly distincts peuvent faire ce que font de nombreux systèmes et transmettre des données entre eux sous forme de JSON, Protobuf ou tout autre format d'échange de données prolifique. La sérialisation et la désérialisation de ces formats sont assez coûteuses et, après tout, étant donné que les deux modules qui souhaitent communiquer entre eux sont probablement exécutés par le même environnement d'exécution côte à côte et non via un réseau, il est possible que la mise en œuvre de cette solution soit meilleure.
Le problème réside dans la manière dont chaque langage de programmation représente les données. Les implémentations de langage peuvent choisir d'utiliser différents codages pour les chaînes, et un langage peut préférer stocker des données séquentielles sous forme de tableau tandis qu'un autre peut préférer les listes chaînées. Pour permettre au code de différents langages de communiquer entre eux, ils doivent s’entendre sur un format commun pour tous les types de données. C'est ce qu'on appelle une interface binaire application , ou ABI. En pratique, aucune d'entre elles ne s'accorde. Habituellement, si l’on souhaite faire communiquer du code écrit dans un langage avec du code écrit dans un autre langage, un pauvre développeur doit s’asseoir et écrire soigneusement (et péniblement) du code à traduire entre les deux langages. Cela nécessite une connaissance approfondie du fonctionnement des deux langues et est extrêmement sujet aux erreurs. Certains écosystèmes linguistiques ont réussi à produire des outils capables de faire cela automatiquement, mais même dans ce cas, cela ne concerne que certaines langues.
Heureusement, le modèle de composant définit un format de données commun à tous les langages, connu sous le nom d'ABI canonique . Pour faciliter la tâche aux humains, il existe également un langage de définition d'interface appelé WebAssembly Interface Types, ou WIT, pour décrire les interfaces des composants.
Le monde de WIT
Nous avons donc tous ces composants, mais comment pouvons-nous savoir où nous pouvons les utiliser ? Après tout, WebAssembly s’exécute dans de nombreux endroits : dans les navigateurs Web, sur les serveurs, en périphérie, sur de petits appareils, etc., tous avec des capacités différentes. WIT nous apporte le concept de mondes . Un monde est l'interface à laquelle un composant se conforme : c'est un ensemble de fonctions qu'un composant peut importer et un ensemble de fonctions qu'il exporte. Cela nous permet de raisonner sur les composants et sur la façon dont ils se composent assez facilement. Voici la définition d'un composant qui vit dans le monde `wasi:cli/command`, qui décrit les composants qui s'exécutent sur une ligne de commande de terminal :
Source : https://github.com/WebAssembly/wasi-cli , modifié pour plus de concision
Ce composant s'occupe d'éléments tels que le système de fichiers et le caractère aléatoire tout en disposant de flux d'entrée et de sortie, mais surtout, il fournit une fonction à exécuter lorsque la commande est invoquée.
Les mondes peuvent être définis par n’importe qui, mais il existe un certain nombre de mondes normalisés pour les composants capables de gérer les requêtes HTTP, d’accéder aux périphériques USB, d’utiliser des modèles d’IA et bien d’autres à venir. Les environnements hôtes peuvent annoncer les mondes qu'ils implémentent pour permettre aux développeurs de savoir facilement quels composants fonctionnent. Étant donné que les composants sont composables, il est également possible d’implémenter certains mondes en termes d’autres mondes et de composer les deux composants. Par exemple, si vous disposez d'un environnement hôte qui implémente un monde de sockets, mais que vous disposez d'un composant qui souhaite effectuer des requêtes HTTP dans un monde HTTP, vous pouvez écrire un composant adaptateur qui implémente le monde HTTP à l'aide de sockets :
Avec une composition simple, votre composant peut désormais fonctionner dans le monde des sockets sans aucune modification ! Les possibilités sont infinies.
L'avenir nous attend
Le modèle de composant est monumental, non seulement pour WebAssembly, mais pour tous les développeurs du monde entier. Cela va fondamentalement changer la façon dont les développeurs raisonneront et développeront les logiciels : il existe déjà des tonnes d’utilitaires, et nous n’en sommes qu’aux débuts. Restez à l’écoute des développements qui se produisent dans l’écosystème WebAssembly, car nous sommes sûrs de voir de plus en plus de cas d’utilisation convaincants apparaître à mesure que l’adoption continue de grimper.