Retour sur le Devfest Nantes 2024 : à la découverte de Server side WASM !

Retour sur le DevFest Nantes 2024

C’était la première fois que j’assistais au DevFest de Nantes, l’un des rendez-vous incontournables pour les passionnés et professionnels du développement web. C’est l’occasion de faire le plein de connaissances et découvrir les nouvelles tendances du secteur. Un grand merci à l’organisation pour cette édition réussie !

Parmi les conférences qui m’ont particulièrement marqué, celle dédiée à WebAssembly (WASM) et à son extension côté serveur, WASI, a retenu mon attention. Voici un tour d’horizon des points essentiels abordés durant cette conférence porté par Etienne Anne de la MAIF et Mathieu Ancelin de SERLI.

WebAssembly (WASM) : le 4ème langage du web

WebAssembly, souvent abrégé en WASM, représente une avancée majeure en permettant d’exécuter du code binaire directement dans le navigateur, peu importe le langage source d’origine (Java, Rust, C, etc.). Ce code est sandboxé, c’est-à-dire isolé dans un environnement sécurisé, garantissant une exécution rapide et optimisée. WebAssembly est désormais reconnu comme le « quatrième langage du web », aux côtés de HTML, CSS et JavaScript. De plus, son standard est géré par le W3C, assurant une compatibilité universelle entre les navigateurs.

Le fonctionnement de WASM repose sur des modules qui contiennent des fonctions exportées, utilisables depuis JavaScript. Ce dernier reste donc présent, jouant le rôle d’intermédiaire pour manipuler le WASM dans le navigateur. Il est également possible d’importer des fonctions ; par exemple, on peut importer la fonction JavaScript console.log() pour afficher un log dans la console.

WASI : l’extension côté serveur

Outre l’exécution dans les navigateurs, la conférence a également exploré l’utilisation de WebAssembly pour les applications côté serveur via le WASI (WebAssembly System Interface). Après tout, puisque WASM est sandboxé, pourquoi se limiter au navigateur ?

Cette extension permet à WASM d’accéder aux fonctionnalités système de l’hôte, comme le système de fichiers ou le réseau, tout en respectant un cadre de sécurité strict. L’idée est que WASI pourrait devenir une alternative à Docker dans certaines applications.

Comparé à Docker, WASI est plus léger, plus rapide et impose des restrictions d’accès plus strictes aux ressources externes de la machine hôte. WASI pourrait ainsi représenter une solution idéale pour des microservices ou des applications nécessitant une isolation sécurisée.

Outils et écosystème autour de WASM/WASI

L’écosystème autour de WASM et WASI s’étoffe, avec des outils pratiques comme Coraza (firewall pour applications web), Open Policy Agent, ou encore Extism, facilitant le travail avec Java et d’autres langages en environnement WASM. Des outils comme Wasmo simplifient également la compilation du code en .wasm.

WIT pour Simplifier l’Interopérabilité entre Modules

Un point encore limitant, abordé durant la conférence, concerne la gestion de la mémoire partagée.

En WebAssembly, la gestion de la mémoire est isolée et complexe à manipuler. Le modèle de mémoire par défaut de WebAssembly n’est pas conçu pour le partage de mémoire de manière sécurisée, car il vise à protéger l’isolation entre les modules pour éviter les erreurs de corruption ou de fuite de données. Le partage de mémoire pose donc des problèmes de synchronisation (verrouillage et déverrouillage) et de « condition de course » (race conditions) — des problèmes bien connus en C et autres langages bas-niveau.

Pour répondre à ces défis, WASI 2.0 introduit des interfaces standardisées, le WebAssembly Interface Type (WIT), pour que des modules WebAssembly, écrits dans différents langages, puissent interagir en se partageant des données complexes. Bien que WIT ne partage pas la mémoire en soi, il permet de contourner certains des défis liés à la mémoire partagée en structurant et facilitant la manière dont les modules s’échangent des données sans devoir passer par des zones de mémoire commune.

En effet, grâce à WIT :

• Les types de données complexes (listes, tuples, structures, etc.) peuvent être convertis et transmis d’un module à un autre sans devoir recourir directement à une mémoire partagée.
• Les échanges de données sont standardisés de sorte qu’on n’ait pas besoin de gérer la synchronisation de la mémoire manuellement.

https://component-model.bytecodealliance.org/design/wit.html

Outils et écosystème autour de WASM/WASI

L’arrivée de WASI Cloud en 2024 introduit un nouveau socle technologique permettant de gérer des fonctionnalités HTTP, SQL, S3, messagerie, ainsi que la gestion des configurations et des secrets. D’une certaine manière, on peut voir WASI Cloud comme un Kubernetes pour WASM, offrant un environnement distribué et flexible aux développeurs souhaitant déployer leurs applications WebAssembly dans le cloud.

Conclusion

Cette conférence sur WASM et WASI m’a permis de mieux comprendre l’avenir prometteur de WebAssembly et ses applications dans un large éventail de contextes, du navigateur aux microservices côté serveur. La technologie évolue rapidement, et les futures versions de WASI, comme la 3.0, s’annoncent encore plus performantes, comblant les derniers manques avec des fonctionnalités supplémentaires telles que l’asynchronisme, les promesses et des plugins pour la gestion de la mémoire en Java (notamment un garbage collector).

En résumé, WASM et WASI offrent une véritable alternative aux technologies de conteneurisation classiques et ouvrent la porte à de nouvelles possibilités pour les développeurs.

Lien vers la conférence