L’architecture des applications web modernes repose généralement sur des bibliothèques JavaScript populaires comme React, Vue.js ou Angular, qui permettent de gérer l’interactivité et le rendu dynamique du contenu dans les navigateurs. Cependant, ces solutions, bien que robustes, viennent avec leurs propres défis, notamment en termes de performance, de complexité et de gestion des différentes interfaces utilisateurs.Dans un mouvement qui pourrait redéfinir certaines approches du développement frontend, Dagger, une plateforme d'intégration et de déploiement continu (CI/CD), a décidé de se détacher des frameworks JavaScript traditionnels pour réinventer son interface utilisateur avec une technologie qui ne cesse de croître : Go et WebAssembly (WASM). Ce choix de remplacer React par Go couplé à WebAssembly a suscité un grand intérêt dans le domaine du développement, tant pour ses avantages que pour les défis qu’il soulève.
Dagger Cloud fournit une traçabilité unifiée et de bout en bout pour les builds et les tests - indépendamment des CI, des environnements de développement, des langages et des plates-formes. Tout ce que Dagger Engine peut exécuter, Dagger Cloud peut le tracer.
Quel en est l'intérêt ? Les développeurs expliquent : « "Qu'est-ce qui n'a pas fonctionné ? Pourquoi est-ce si lent ?" Si vous avez déjà perdu du temps à regarder les journaux de CI pour répondre à ces questions, il est temps d'adopter le traçage. Cela vous aidera à optimiser vos constructions et à résoudre plus rapidement les problèmes lorsque les choses tournent mal ».
Le contexte : un besoin de cohérence et de performance
« Il y a quelques semaines, nous avons lancé Dagger Cloud v3, une toute nouvelle interface utilisateur pour Dagger Cloud. L'une des principales différences entre la v3 et son prédécesseur v2 est que la nouvelle interface utilisateur est écrite en WebAssembly (WASM) à l'aide de Go. À première vue, ce choix peut sembler étrange (Go n'est généralement pas le premier langage auquel on pense lorsqu'on décide de programmer une interface utilisateur Web) mais nous avions de bonnes raisons ».
Avant de s'engager dans cette refonte, Dagger faisait face à une situation où deux interfaces utilisateurs distinctes étaient en parallèle :
- L'interface de terminal (TUI) développée en Go, directement intégrée au CLI de Dagger.
- L'interface Cloud développée en React pour le tableau de bord web, utilisé pour l’interaction avec les utilisateurs.
Maintenir deux interfaces différentes engendrait des défis majeurs. D’une part, la duplication du code ralentissait le développement. Chaque nouvelle fonctionnalité devait être réécrite et testée sur deux plateformes distinctes, ce qui non seulement alourdissait le processus de développement, mais aussi augmentait les risques d’incohérences entre les deux interfaces. D’autre part, la gestion des performances de l’interface Cloud devenait de plus en plus complexe. En particulier, la plateforme devait gérer de grandes quantités de données en temps réel, ce qui ralentissait l’expérience utilisateur et rendait l'interface moins réactive, surtout dans des scénarios de forte utilisation.
Deux bases de code = plus de travail, moins de fonctionnalités
Dagger fonctionne en construisant un DAG d'opérations et en les évaluant, souvent en parallèle. Par nature, il s'agit d'une chose difficile à afficher. Pour aider les utilisateurs à s'y retrouver, nous proposons deux interfaces de visualisation en temps réel : l'interface terminale de Dagger (TUI), incluse dans le CLI de Dagger, et Dagger Cloud, un tableau de bord Web en ligne. L'interface utilisateur de Dagger est implémentée en Go, et Dagger Cloud (pré-v3) a été écrit en React.
Il est évident que nous voulons que les deux interfaces utilisateur soient aussi proches que possible l'une de l'autre. Mais l'interprétation du flux d'événements de Dagger en temps réel et la production d'une interface utilisateur sont des tâches assez complexes. Certains des flux d'événements les plus complexes que nous ayons vus contiennent des centaines de milliers de données OpenTelemetry, et la gestion des structures de données qui les entourent devient très compliquée, très rapidement. L'interface Web ne pouvait souvent pas suivre l'énorme volume de données qu'elle devait traiter et elle devenait lente et laggy ; pour résoudre ce goulot d'étranglement des performances, nous avons été contraints d'adopter un modèle d'implémentation différent pour l'application React.
Nous nous sommes donc retrouvés avec deux interfaces essayant d'accomplir la même chose, l'une dans un langage et un écosystème (TypeScript/React), l'autre dans un langage et un écosystème totalement différents (Go), et nous ne pouvions pas facilement partager la logique métier entre elles. En tant que petite équipe, nous devons livrer rapidement. Avoir à réimplémenter chaque fonctionnalité deux fois était une taxe massive sur notre vélocité.
Nous avons commencé à réfléchir à une nouvelle approche de Dagger Cloud, avec deux objectifs principaux :
Dagger fonctionne en construisant un DAG d'opérations et en les évaluant, souvent en parallèle. Par nature, il s'agit d'une chose difficile à afficher. Pour aider les utilisateurs à s'y retrouver, nous proposons deux interfaces de visualisation en temps réel : l'interface terminale de Dagger (TUI), incluse dans le CLI de Dagger, et Dagger Cloud, un tableau de bord Web en ligne. L'interface utilisateur de Dagger est implémentée en Go, et Dagger Cloud (pré-v3) a été écrit en React.
Il est évident que nous voulons que les deux interfaces utilisateur soient aussi proches que possible l'une de l'autre. Mais l'interprétation du flux d'événements de Dagger en temps réel et la production d'une interface utilisateur sont des tâches assez complexes. Certains des flux d'événements les plus complexes que nous ayons vus contiennent des centaines de milliers de données OpenTelemetry, et la gestion des structures de données qui les entourent devient très compliquée, très rapidement. L'interface Web ne pouvait souvent pas suivre l'énorme volume de données qu'elle devait traiter et elle devenait lente et laggy ; pour résoudre ce goulot d'étranglement des performances, nous avons été contraints d'adopter un modèle d'implémentation différent pour l'application React.
Nous nous sommes donc retrouvés avec deux interfaces essayant d'accomplir la même chose, l'une dans un langage et un écosystème (TypeScript/React), l'autre dans un langage et un écosystème totalement différents (Go), et nous ne pouvions pas facilement partager la logique métier entre elles. En tant que petite équipe, nous devons livrer rapidement. Avoir à réimplémenter chaque fonctionnalité deux fois était une taxe massive sur notre vélocité.
Nous avons commencé à réfléchir à une nouvelle approche de Dagger Cloud, avec deux objectifs principaux :
- Unifier les bases de code, afin d'éliminer les doublons et de rendre plus efficace la livraison de nouvelles fonctionnalités.
- Tenir la promesse d'une interface Web claire et rapide, à la hauteur de la vitesse et de la performance de l'interface du terminal.
Go et WebAssembly : la solution choisie
Le choix de Go et WebAssembly ne s’est pas fait par hasard. Ce combo représente une approche relativement novatrice mais prometteuse pour le développement frontend, et ce pour plusieurs raisons.
Go : La Cohérence et la Productivité
Go, un langage de programmation compilé développé par Google, est particulièrement apprécié pour sa simplicité, sa rapidité et son efficacité. Son adoption au sein de Dagger était déjà bien ancrée pour le développement de leur interface en ligne de commande (CLI) et du backend. L'utilisation de Go pour l'interface utilisateur présente plusieurs avantages :
- Unité de code : En choisissant Go, l’équipe de développement a pu unifier l’écriture du code backend et frontend. Cela facilite non seulement la maintenance, mais aussi la collaboration entre les équipes de développement, qui sont toutes familières avec le même langage.
- Haute performance : Go étant un langage compilé, il offre des performances supérieures à celles des langages interprétés comme JavaScript. Ce facteur est essentiel pour des applications qui manipulent une grande quantité de données, comme c’est le cas de Dagger.
- Simplicité : Go est réputé pour sa syntaxe simple et son faible coût d’apprentissage, ce qui facilite la prise en main pour les développeurs, même ceux venant de langages de programmation plus complexes.
WebAssembly : L’exécution nativement dans le navigateur
WebAssembly (WASM) est une technologie qui permet d'exécuter du code à grande vitesse dans les navigateurs, presque à la vitesse native. L’une des caractéristiques principales de WASM est sa capacité à exécuter des langages autres que JavaScript dans l’environnement du navigateur, avec un rendu extrêmement rapide et efficace.
- [...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.
Envoyé par boboss123
, dommage que, comme Smalltalk (et Eiffel, Ada, etc.) ce ne soit pas "libre", free...