Dagger a publié un REX intéressant sur comment et pourquoi le frontend React de Dagger Cloud a été remplacé par le duo Go et WebAssembly. Cette migration, techniquement importante, concerne la V3 du service cloud. Dagger expose plusieurs services : Cloud et CLI. Or, la partie CLI (Terminal UI) est écrite en Go alors que la partie Cloud (ante V3) l'était en React. Bref : deux codes sources à maintenir et à faire évoluer pour avoir des UI les plus propres possibles.

Une des difficultés est le volume de données provenant notamment d'OpenTelemetry. Le front devait donc absorber cette masse de données et l'afficher. Sur le long terme, maintenir deux bases de code avec des technologies totalement différentes n'était plus tenable. Comme les 2 fronts remplissent les mêmes fonctions, il fallait implémenter deux fois les modifications et les évolutions.
"Nous avons commencé à réfléchir à une nouvelle approche de Dagger Cloud, avec deux objectifs principaux :
- Unifier les bases de code, pour éliminer les doublons et rendre plus efficace la livraison de nouvelles fonctionnalités
- Tenir la promesse d'une interface utilisateur Web claire et réactive, à la hauteur de la vitesse et des performances de l'interface utilisateur du terminal"
L'objectif premier de ce changement technique était de pouvoir réutiliser le code entre Cloud et TUI. Il a été décidé que Go était le plus simple. L'équipe de développement avait déjà une forte compétence en Go et cela semblait plus naturel que de tout miser sur React et JavaScript. En plus de Go, WebAssembly a été choisi mais il y avait des inconvénients :
1 Go + WebAssembly n'est pas aussi mature que React et JS. L'équipe avait conscience qu'il fallait créer les composants nécessaires
2 Les apps WebAssembly sont limitées à 2 Go de mémoire, une contrainte liée aux navigateurs
Une fois le choix acté, comment faire pour construire le nouveau front ? "Nous avons décidé de créer la nouvelle interface utilisateur basée sur WebAssembly dans le framework Go-app. Go-app est un framework de haut niveau spécifiquement destiné aux applications Web progressives (PWA) dans WebAssembly. Il offre des avantages clés de Go, comme une compilation rapide et un typage statique natif, et il suit également un modèle d'interface utilisateur basé sur des composants, comme React, ce qui a facilité la transition."
Pour convaincre les autres équipes et surtout pour réduire les risques liés à une réécriture complète, durant un mois, des prototypes ont été développés pour éprouver les choix techniques. Le principal défi fut la contrainte mémoire : il fallait donc être très prudent sur la conception de l'architecture du front et réussir à optimiser le code.
De nombreuses informations ont été tirées de cette migration, dont :
- la gestion mémoire a été un défi tout au long du développement. Par exemple : afficher 200 000 lignes sans faire crasher le front
- Go WASM est assez lent pour parser une grande quantité de JSON, ce qui oblige à repenser le backend
- Initialement le WebAssembly pesait 32 Mo. En utilisant la compression Brotli, le fichier pèse - 5 Mo
- l'écriture des composants UI n'a pas été aussi difficile qu'attendu
- possibilité d'utiliser des paquets NPM dans le code Go si besoin
- l'outillage de Go-app est plus limité que celui de React et n'est pas intégré aux navigateurs, mais il fut suffisant
- Dagger Cloud est une PWA. Il était donc possible de créer une app native desktop et mobile
" Notre passage de React à WASM a permis une expérience utilisateur plus cohérente sur toutes les interfaces Dagger, ainsi que de meilleures performances globales et une utilisation de la mémoire plus faible, en particulier lors du rendu de traces volumineuses et complexes.
D'un point de vue technique également, les avantages pour notre équipe sont considérables. Les optimisations impliquent très souvent autant, voire plus, de travail que la mise en œuvre réelle de fonctionnalités. C'est donc formidable de ne pas avoir à passer du temps à optimiser l'interface utilisateur Web, puis plus de temps à optimiser l'interface utilisateur de test, et de se concentrer plutôt sur la fourniture de nouvelles fonctionnalités." conclut le REX.