Qu’est-ce que le modèle de composants WebAssembly ?

Oscar Spencer

WebAssembly, ou Wasm en abrégé, s’est imposé à maintes reprises comme une technologie révolutionnaire grâce à sa vitesse d’exécution élevée, proche des performances natives, au vaste choix de langages de programmation qu’il offre et à son robuste modèle d’exécution en bac à sable, qui refuse tout accès par défaut. Il est déjà très largement utilisé sur le Web et s’est également imposé comme un acteur majeur côté serveur.

Tout écosystème en plein essor a besoin d’une vision définissant la manière dont tous ses éléments s’articulent, et c’est précisément là qu’intervient le modèle de composants WebAssembly. Le modèle de composants est un système qui facilite les interactions entre les différentes unités de code WebAssembly, ainsi qu’entre le code WebAssembly et un environnement hôte. Il repose entièrement sur le concept de composants WebAssembly, qui sont essentiellement des modules Wasm classiques intégrant des types de données encodés. Ces types permettent de générer en arrière-plan du code de liaison grâce auquel les composants peuvent communiquer entre eux de manière fluide.

Le modèle de composants ouvre une nouvelle ère du développement logiciel moderne : les développeurs peuvent sélectionner des composants issus de n’importe quel écosystème de langage de programmation et les assembler au sein d’une même application. Vous avez une application de traitement de données en Python, mais avez besoin d’un analyseur performant écrit en Rust ? Aucun problème. Une équipe de votre organisation maîtrise Go, tandis qu’une autre ne développe qu’en JavaScript ? Là encore, aucun souci : chaque équipe peut créer des composants WebAssembly qui s’assemblent sans difficulté.

Pourquoi en avons-nous besoin, d’un point de vue technique ?

WebAssembly est confronté à un problème que nous avons rencontré avec presque toutes les nouvelles plateformes d’exécution de code : comment partager des données entre des unités de code distinctes de manière sûre, sécurisée et efficace, alors qu’elles peuvent avoir été produites par des chaînes d’outils issues de langages de programmation totalement différents ? En règle générale, deux modules WebAssembly distincts pourraient procéder comme de nombreux systèmes et échanger des données au format JSON, Protobuf ou dans tout autre format d’échange de données répandu. La sérialisation et la désérialisation de ces formats sont relativement coûteuses. Or, puisque les deux modules qui souhaitent communiquer sont probablement exécutés côte à côte par le même environnement d’exécution, et non via un réseau, il devrait être possible de mettre en œuvre une solution plus performante.

La difficulté réside dans la manière dont chaque langage de programmation représente les données. Les implémentations des langages peuvent choisir différents encodages pour les chaînes de caractères, et un langage peut préférer stocker les données séquentielles dans un tableau, tandis qu’un autre privilégiera les listes chaînées. Pour permettre à du code écrit dans différents langages de communiquer, il faut convenir d’une représentation commune pour tous les types de données. C’est ce que l’on appelle une interface binaire-programme, ou ABI. En pratique, aucun langage ne s’accorde avec les autres. Généralement, lorsqu’on souhaite faire communiquer du code écrit dans un langage avec du code écrit dans un autre, un malheureux développeur doit s’atteler à écrire soigneusement — et péniblement — le code permettant d’effectuer la conversion entre les deux langages. Cela exige une connaissance approfondie du fonctionnement de chacun d’eux et présente un risque d’erreur particulièrement élevé. Certains écosystèmes de langages sont parvenus à créer des outils capables d’automatiser cette tâche, mais même dans ce cas, ils ne prennent en charge qu’une sélection de langages.

Heureusement, le modèle de composants définit une représentation commune des données pour tous les langages, appelée ABI canonique. Pour faciliter les choses, il existe également un langage de définition d’interface appelé WebAssembly Interface Types, ou WIT, qui permet de décrire les interfaces des composants.

Le monde de WIT

Nous disposons donc de tous ces composants, mais comment savoir où nous pouvons les utiliser ? Après tout, WebAssembly s’exécute dans de nombreux environnements — navigateurs web, serveurs, périphérie du réseau, appareils aux ressources limitées, etc. — qui offrent tous des capacités différentes. WIT introduit le concept de « mondes ». Un monde est l’interface à laquelle un composant se conforme : il s’agit d’un ensemble de fonctions qu’un composant peut importer et d’un ensemble de fonctions qu’il exporte. Cela nous permet de comprendre assez facilement les composants et la manière dont ils s’assemblent. Voici la définition d’un composant appartenant au monde `wasi:cli/command`, qui décrit les composants s’exécutant dans un terminal en ligne de commande :

Source : https://github.com/WebAssembly/wasi-cli, modifié par souci de concision

Ce composant prend en charge des éléments tels que le système de fichiers et la génération aléatoire, ainsi que des flux d’entrée et de sortie. Mais surtout, il fournit une fonction à exécuter lorsque la commande est appelée.

Les mondes peuvent être définis par n’importe qui, mais il existe plusieurs mondes en cours de normalisation pour les composants capables de traiter des requêtes HTTP, d’accéder à des périphériques USB, d’utiliser des modèles d’IA, et bien d’autres sont à venir. Les environnements hôtes peuvent indiquer les mondes qu’ils implémentent afin que les développeurs puissent facilement savoir quels composants sont compatibles. Comme les composants sont composables, il est également possible d’implémenter certains mondes à partir d’autres mondes et de combiner les deux composants. Par exemple, si vous disposez d’un environnement hôte qui implémente un monde de sockets, mais que vous avez 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 :

Grâce à une simple composition, votre composant peut désormais fonctionner dans l’univers des sockets sans aucune modification ! Les possibilités sont infinies.

L’avenir qui nous attend

Le modèle de composants constitue une avancée majeure, non seulement pour WebAssembly, mais aussi pour l’ensemble des développeurs, partout dans le monde. Il va profondément transformer la manière dont les développeurs conçoivent et créent des logiciels : il offre déjà une multitude de possibilités, alors que nous n’en sommes encore qu’aux prémices. Suivez de près les évolutions de l’écosystème WebAssembly : à mesure que son adoption progressera, nous verrons sans aucun doute émerger des cas d’usage toujours plus convaincants.

À propos de l’auteur

Oscar Spencer

Autres articles de Oscar Spencer