Lors du développement d’une nouvelle technologie, comme Bencher, il existe une tension fondamentale entre le désir de choisir une technologie ennuyeuse et battre les moyennes. Sur le moment, il peut être difficile de dire exactement où l’on se situe dans ce tir à la corde. Tous les trois ans, le langage de programmation Rust sort avec une nouvelle édition Rust. Je pense que c’est une bonne cadence. C’est assez long pour permettre de réels progrès. Pourtant, assez court pour ne pas s’éloigner trop. Avec Bencher atteignant ses 3 ans ce printemps, j’ai pensé qu’il serait temps de s’arrêter et réfléchir à toutes les décisions d’ingénierie qui nous ont amenés ici.
Dans cet article, je vais revenir sur l’utilisation des “jetons d’innovation” de Bencher au cours des trois dernières années. Bencher est une suite open source d’outils de benchmarking continu. Je commencerai par le frontend de l’architecture de Bencher et descendrai tout au long de la pile. À chaque étape, je discuterai de la façon dont nous sommes arrivés ici et donnerai un verdict binaire sur la manière dont chaque décision d’ingénierie s’est avérée.
Frontend
Bibliothèque Frontend
En tant que développeur C++ en reconversion, je suis un assez grand fan de Rust. Si j’avais eu le choix, j’aurais pu écrire Bencher en Rust full-stack. Si vous fouillez dans les recoins profonds du [répertoire Bencher][bencher github], vous me verrez essayer de faire exactement cela. J’ai expérimenté avec [Yew][yew github], [Seed][seed github] et [Sycamore][sycamore github]. Bien qu’ils puissent fonctionner très bien pour certains projets, il y avait un grand point de blocage que je ne pouvais tout simplement pas surmonter : l’[Interopérabilité avec JavaScript][js ffi].
Bien que l’interopérabilité JS soit possible à partir de WASM via Rust, cela n’allait pas être facile. Je savais que je voulais que Bencher ait des graphiques hautement interactifs. Cela signifiait utiliser une bibliothèque comme [D3][d3 github], ce qui impliquait l’interopérabilité JS.
Alors, si je devais utiliser JavaScript, quelle bibliothèque devrais-je choisir ?
En revenant à ces caisses Rust que j’avais expérimentées, Yew est l’analogue en Rust des [React Hooks][react hooks]. J’avais construit et déployé un frontend en utilisant React Hooks dans le passé, donc je connaissais le mieux ce framework. Cependant, j’ai trouvé le cycle de vie de React Hooks très compliqué et plein de pièges, de cas particuliers étranges.
J’aimais vraiment les principes de base de la [programmation réactive fonctionnelle][functional reactive programming] (FRP). Cela m’a amené à essayer à la fois [Elm][elm] et son analogue en Rust, Seed. Malheureusement, l’utilisation d’Elm souffre des mêmes problèmes que l’utilisation de Rust. Elm nécessite sa propre [Interopérabilité avec JavaScript][elm js interop]. J’ai aussi trouvé que [L’Architecture Elm][the elm architecture] était un peu trop restrictive à mon goût.
De tous les frameworks Rust que j’ai essayés, j’aimais le plus Sycamore. Sycamore a été inspiré par [Solid][solid github]. Plus j’en apprenais sur Solid, plus je l’aimais. Contrairement à React, Solid n’utilise pas de [DOM virtuel][react virtual dom]. Au lieu de cela, il se compile en bon vieux JavaScript. Cela le rend beaucoup plus rapide, plus petit et plus facile à travailler. Solid est composé de quelques primitives puissantes qui permettent une réactivité fine. Lorsque quelque chose dans l’UI est mis à jour, seul le code qui en dépend sera réexécuté. Au cours des trois dernières années, j’ai trouvé Solid très agréable à utiliser.
Technologie
Verdict
Yew
❌
Seed
❌
Sycamore
❌
Elm
❌
SolidJS
✅
Frontend Framework
Solid est en soi juste une bibliothèque. Pour construire un frontend moderne, j’avais besoin d’utiliser un framework d’application web complet. Voulant garder les choses simples, j’ai mis tous mes œufs dans le panier de Solid et j’ai initialement utilisé SolidStart. À l’époque, SolidStart ne supportait que les applications monopages (SPAs).
Une SPA était suffisante pour commencer. Cependant, avec le temps, j’ai dû commencer à me soucier de choses comme le SEO. Je commençais à écrire beaucoup plus de documentation Bencher. Je prévoyais également la section Apprendre du site. Cela signifiait que j’avais besoin à la fois du rendu côté client (CSR) et de la génération de site statique (SSG). SolidStart était très jeune et ne répondait pas à tous mes besoins.
Après avoir découvert Astro et l’avoir essayé, j’ai décidé de porter l’ensemble du frontend de Bencher de SolidStart vers Astro. Cela avait quelques inconvénients. Le plus évident était l’effort impliqué. Honnêtement, ce n’était pas trop mal. Astro a son architecture îlots et une intégration Solid de premier ordre. J’ai également pu reprendre beaucoup de la logique dont j’avais besoin à partir du Solid Router, et cela a plutôt bien fonctionné.
Le grand compromis qui est toujours présent aujourd’hui est que Bencher est passé d’une application monopage à une application multipage. La plupart des endroits où vous cliquez dans la console entraînent un rechargement complet de la page. Astro avait la promesse de transitions de vue lorsque j’ai effectué le changement. Je les ai essayées, mais elles étaient boguées. J’ai encore besoin de revenir dessus.
Entre-temps, SolidStart semble avoir rattrapé un peu de son retard. Ils supportent maintenant à la fois CSR et SSG. Bien que je n’aie pas vérifié s’ils fonctionnent tous deux sur le même site, comme j’en ai besoin. C’est de l’histoire ancienne.
Technologie
Verdict
SolidStart
❌
Astro
✅
Langage Frontend
Astro dispose d’un support TypeScript intégré. Dans la transition de SolidStart à Astro, j’ai également commencé la transition de JavaScript à TypeScript. La configuration TypeScript de Bencher est réglée sur le paramètre strictest d’Astro. Cependant, Astro ne vérifie pas le typage pendant les builds. Au moment de la rédaction, Bencher a encore 604 erreurs de type. Ces erreurs de type sont utilisées plus comme des indices lors de l’édition de code, mais elles ne bloquent pas le build (pour l’instant).
J’ai également ajouté Typeshare pour synchroniser les types de données Rust de Bencher avec le frontend TypeScript. Cela a été incroyablement utile pour développer la Bencher Console. De plus, tous les validateurs de champs pour des éléments comme les noms d’utilisateur, emails, etc., sont partagés entre le code Rust et le frontend TypeScript via WASM. Cela a été un peu compliqué de faire fonctionner WASM à la fois dans SolidStart et Astro. La plus grande catégorie d’erreurs que j’ai vue dans le frontend concerne les endroits où une fonction WASM est appelée mais où le module WASM n’a pas encore été chargé. J’ai compris comment le réparer, mais il m’arrive encore parfois d’oublier et cela réapparaît.
Avoir à la fois les types et les validateurs partagés auto-générés depuis le code Rust a considérablement facilité l’interfaçage avec le frontend. Ils sont tous les deux vérifiés en CI, donc ils ne sont jamais désynchronisés. Tout ce que j’ai à faire, c’est de m’assurer que les requêtes HTTP sont bien formées, et tout fonctionne simplement. Cela rend le fait de ne pas pouvoir utiliser Rust full-stack un peu moins frustrant.
Technologie
Verdict
Rust
❌
JavaScript
❌
TypeScript
✅
Typeshare
✅
WASM
✅
Hébergement Frontend
Ma décision initiale de m’investir totalement dans Solid a été fortement influencée par le fait que
Netlify a embauché le créateur de Solid pour qu’il travaille dessus à plein temps.
Vous voyez, le principal concurrent de Netlify est Vercel.
Vercel a créé et maintient Next.js.
Et j’ai pensé que Netlify voulait que Solid soit leur Next.js.
Par conséquent, je pensais qu’il n’y aurait pas de meilleur endroit pour héberger un site SolidStart que Netlify.
Par défaut, Netlify essaie de vous faire utiliser leur système de build.
Utiliser le système de build de Netlify rend très difficile la réalisation de déploiements atomiques.
Netlify publierait toujours le frontend même si la chaîne backend échouait.
Très mauvais !
Cela m’a amené à construire le frontend dans le même environnement CI/CD que le backend
et ensuite simplement télécharger la dernière version sur Netlify avec leur CLI.
Lorsque j’ai effectué la transition de SolidStart à Astro,
j’ai pu garder la même configuration CI/CD.
Astro a une intégration Netlify de première partie.
Bencher a réussi à rester sous le niveau gratuit de Netlify pendant un certain temps.
Cependant, avec la popularité croissante de Bencher,
nous avons commencé à dépasser certaines des limites du niveau gratuit.
J’ai envisagé de déplacer le site Astro vers sst sur AWS.
Cependant, les économies de coûts ne semblent pas en valoir la peine à ce stade.
L’une de mes principales considérations lors de la sélection d’un cadre de serveur HTTP Rust était le support intégré de la spécification OpenAPI. Pour les mêmes raisons pour lesquelles j’ai investi dans la mise en place de Typeshare et WASM sur le frontend, je voulais la capacité de générer automatiquement à la fois la documentation de l’API et les clients à partir de cette spécification. Il était important pour moi que cette fonctionnalité soit intégrée et non un module complémentaire tiers. Pour que l’automatisation en vaille vraiment la peine, elle doit fonctionner presque 100% du temps. Cela signifie que la charge de maintenance et de compatibilité doit incomber aux ingénieurs du cadre central eux-mêmes. Sinon, vous finirez inévitablement par vous retrouver dans un enfer de cas limites.
Une autre considération clé était le risque d’abandon. Il existe plusieurs cadres HTTP Rust autrefois prometteurs qui sont maintenant presque à l’abandon. Le seul cadre que j’ai trouvé qui avait un support intégré de la spécification OpenAPI et sur lequel j’étais prêt à parier était Dropshot. Dropshot a été créé et est toujours maintenu par Oxide Computer.
Je n’ai eu qu’un seul problème majeur avec Dropshot jusqu’à présent. Lorsqu’une erreur est générée par le serveur API, cela provoque un échec CORS sur le frontend en raison de l’absence d’en-têtes de réponse. Cela signifie que le frontend web ne peut pas afficher de messages d’erreur très utiles aux utilisateurs. Au lieu de travailler sur l’intégration d’une correction, j’ai mis mes efforts à rendre Bencher plus facile et intuitif à utiliser. Mais il s’avère que la solution était moins de 100 lignes de code. C’est pour ma pomme !
En passant, le cadre axum n’avait pas encore été publié lorsque j’ai commencé à travailler sur Bencher. S’il avait été disponible à l’époque, j’aurais pu essayer de l’associer à l’un des nombreux modules complémentaires OpenAPI tiers, malgré mon meilleur jugement. Heureusement pour moi, axum n’était pas encore là pour me tenter. Dropshot a été un excellent choix. Voir la section Client API pour plus d’informations à ce sujet.
Technologie
Verdict
Dropshot
✅
Base de données
J’ai essayé de garder Bencher aussi simple que possible.
La première version de Bencher prenait tout,
y compris les résultats des benchmarks eux-mêmes via les paramètres de requête URL.
J’ai rapidement appris que tous les navigateurs ont une limite sur la longueur des URL.
Cela a du sens.
Ensuite, j’ai envisagé de stocker les résultats des benchmarks dans git
et de simplement générer un fichier HTML statique avec les graphiques et les résultats.
Cependant, cette approche a deux inconvénients majeurs.
Premièrement, le temps de git clone finirait par devenir intenable pour les utilisateurs intensifs.
Deuxièmement, toutes les données historiques devraient être présentes dans le fichier HTML,
conduisant à des temps de chargement initial très longs pour les utilisateurs intensifs.
Un outil de développement devrait aimer ses utilisateurs intensifs, pas les punir.
Il s’avère qu’il existe une solution à mon problème.
Cela s’appelle une base de données.
Alors pourquoi ne pas simplement utiliser Postgres et en rester là ?
Eh bien, je voulais vraiment que les gens puissent héberger Bencher eux-mêmes.
Plus je pouvais simplifier l’architecture,
plus il serait facile (et bon marché) pour les autres de l’héberger eux-mêmes.
J’allais déjà nécessiter deux conteneurs en raison du frontend et du backend séparés.
Pourrais-je éviter un troisième ? Oui !
Avant Bencher, je n’avais utilisé SQLite que comme base de données de test.
L’expérience développeur était fantastique, mais je n’avais jamais envisagé de l’utiliser en production.
Puis je suis tombé sur Litestream.
Litestream est un outil de récupération en cas de sinistre pour SQLite.
Il fonctionne en arrière-plan et réplique continuellement les changements vers S3
ou tout autre magasin de données de votre choix.
Cela le rend à la fois facile à utiliser et incroyablement économique à exécuter,
puisque S3 ne facture pas les écritures.
Pensez à quelques centimes par jour pour une petite instance.
Lorsque j’ai découvert Litestream pour la première fois,
il y avait aussi la promesse de répliques de lecture en direct qui devaient arriver bientôt.
Cependant, ceci ne s’est jamais réalisé.
L’alternative suggérée était un projet successeur par le même développeur
appelé LiteFS.
Cependant, il y a des inconvénients majeurs à LiteFS.
Il n’offre pas de récupération en cas de sinistre intégrée, si toutes les réplicas tombent en panne.
Pour avoir plusieurs réplicas,
vous devez infecter votre logique d’application avec le concept de lecteur ou d’écrivain.
Et le blocage absolu était qu’il nécessite une instance de Consul
pour gérer les réplicas en permanence.
L’ensemble du but de l’utilisation de SQLite était d’éviter encore un autre service.
Heureusement, je n’ai pas essayé d’utiliser LiteFS avec Bencher Cloud non plus,
car LiteFS Cloud a été abandonné un an après son lancement,
et LiteFS est désormais presque à l’arrêt.
Actuellement, le petit temps d’arrêt entre les déploiements est géré par le CLI de Bencher.
À l’avenir, je prévois de passer à des déploiements sans temps d’arrêt en utilisant Kamal.
Avec Rails 8.0 par défaut vers Kamal et SQLite,
je me sens assez confiant que Kamal et Litestream devraient bien fonctionner ensemble.
Technologie
Verdict
Paramètres de requête URL
❌
git + HTML
❌
SQLite
✅
Litestream
✅
LiteFS
❌
Pilote de Base de Données
Plus je me rapproche de la base de données, plus je souhaite que les choses soient fortement typées.
C’est acceptable de jouer un peu plus librement sur le frontend.
Si je fais une erreur, tout sera corrigé avec la prochaine mise en production.
Cependant, si je corromps la base de données, c’est bien plus compliqué à rectifier.
Avec cela en tête, j’ai choisi d’utiliser Diesel.
Diesel est un mapper relationnel d’objets (ORM) fortement typé et un constructeur de requêtes pour Rust.
Il vérifie toutes les interactions avec la base de données à la compilation, empêchant ainsi les erreurs d’exécution.
Cette vérification à la compilation fait également de Diesel une abstraction sans coût sur le SQL.
À part un petit bug de mon côté lors de l’optimisation des performances pour rendre les choses 1200 fois plus rapides,
je n’ai eu aucune erreur SQL en exécutant Diesel.
De la même manière que j’ai choisi Netlify pour l’hébergement de mon frontend parce que j’utilisais Solid, j’ai choisi Fly.io pour l’hébergement de mon backend parce que j’utilisais Litestream. Fly.io avait tout juste embauché le créateur de Litestream pour qu’il travaille dessus à plein temps. Comme mentionné ci-dessus, ce travail sur Litestream a finalement été cannibalisé par LiteFS, et LiteFS est maintenant mort. Donc cela ne s’est pas vraiment passé comme je l’avais espéré.
À l’avenir, lorsque je passerai à Kamal, je quitterai également Fly.io. Fly.io a connu deux pannes majeures qui ont mis Bencher hors ligne pendant une demi-journée à chaque fois. Mais le plus gros problème est le décalage d’impédance qui vient de l’utilisation de Litestream.
Chaque fois que je me connecte au tableau de bord Fly.io, je vois cet avertissement :
ℹ Votre application fonctionne sur une seule machine
Mettez votre application à l’échelle et exécutez-la sur plusieurs Machines pour assurer une haute disponibilité avec une commande :
fly scale count 2
Consultez la documentation pour plus de détails sur la mise à l’échelle.
Mais avec Litestream, vous ne pouvez toujours pas avoir plus d’une machine ! Vous n’avez jamais fourni la réplication en lecture, comme vous l’aviez promis !
Donc oui, c’est un peu ironique et frustrant. À un moment donné, j’ai regardé libSQL et Turso. Cependant, libSQL nécessite un serveur backend spécial pour la réplication, ce qui le rend incompatible avec Diesel. Quoi qu’il en soit, il semble que j’ai esquivé une autre fin de vie là aussi. Je suis très intéressé de voir ce que Turso va faire avec Limbo, leur réécriture de SQLite en Rust. Mais je ne ferai pas ce changement de sitôt. La prochaine étape est une VM agréable, ennuyeuse et stable fonctionnant avec Kamal.
Le backend AWS S3 pour la réplication Litestream a fonctionné parfaitement. Même avec le retrait brutal autour de Litestream et Fly.io, je pense toujours avoir fait le bon choix en utilisant Litestream avec Bencher. Je commence à rencontrer quelques problèmes de mise à l’échelle avec Bencher Cloud, mais c’est un bon problème à avoir.
Au fil du temps, je découvre de plus en plus de fonctionnalités utiles que Clap peut offrir. C’est un peu embarrassant, mais je viens de découvrir récemment l’option default_value. Toutes ces capacités aident vraiment à réduire la quantité de code que je dois maintenir dans le bencher CLI.
Un facteur majeur dans le choix de Dropshot comme
framework de serveur HTTP de Bencher était sa capacité intégrée à générer une spécification OpenAPI.
J’avais l’espoir qu’un jour, je pourrais auto-générer un client API à partir de cette spécification.
Un an plus tard environ, les créateurs de Dropshot ont livré : Progenitor.
Progenitor est le yin au yang de Dropshot.
En utilisant la spécification OpenAPI de Dropshot, Progenitor peut générer un client API Rust
soit dans un modèle positionnel :
Personnellement, je préfère le dernier,
c’est donc celui que Bencher utilise.
Progenitor peut également générer un CLI complet Clap pour interagir avec l’API.
Cependant, je ne l’ai pas utilisé.
J’avais besoin d’avoir un contrôle plus précis sur les choses,
surtout pour des commandes comme bencher run.
Le seul inconvénient notable que j’ai trouvé avec les types générés est que
en raison des limitations du schéma JSON, vous ne pouvez pas simplement utiliser un Option<Option<Item>>
lorsque vous devez pouvoir distinguer entre une clé item manquante et une clé item avec la valeur définie à null.
Cela est possible avec quelque chose comme double_option,
mais tout semble identique au niveau du schéma JSON.
Utiliser une struct interne enum aplatie ou sans balisage
ne fonctionne pas bien avec Dropshot.
La seule solution que j’ai trouvée était d’utiliser un enum sans balisage au niveau supérieur.
Il n’y a que deux champs de ce type dans toute l’API pour le moment,
donc ce n’est pas un gros problème.
Technologie
Verdict
Progenitor
✅
Développement
Environnement de Développement
Lorsque j’ai commencé à travailler sur Bencher, les gens appelaient à la fin de localhost.
J’avais déjà bien dépassé le besoin d’un nouvel ordinateur portable de développement,
alors j’ai décidé d’essayer un environnement de développement dans le cloud.
À l’époque, GitHub Workspaces n’était pas généralement disponible (GA) pour mon cas d’utilisation,
donc j’ai choisi Gitpod.
Cette expérience a duré environ six mois.
Ma conclusion : les environnements de développement dans le cloud ne fonctionnent pas bien pour les projets parallèles.
Vous voulez intervenir et effectuer cinq minutes de travail ?
Impossible ! Vous allez vous asseoir là et attendre que votre environnement de développement se réinitialise pour la 1 000ème fois.
Oh, vous avez tout un après-midi le week-end pour vraiment avancer dans votre travail ?
Impossible ! Votre environnement de développement va juste s’arrêter de fonctionner de manière aléatoire pendant que vous l’utilisez. Encore et encore et encore.
J’ai rencontré ces problèmes en tant qu’utilisateur payant.
À 25 $/mois, je pourrais obtenir un tout nouveau MacBook Pro M1 avec des spécifications bien meilleures tous les cinq ans.
Quand Gitpod a annoncé qu’ils modifiaient leur tarification d’un taux fixe à un modèle basé sur l’utilisation,
je les ai simplement laissés annuler mon plan et je me suis rendu sur apple.com.
Peut-être que tout cela était un problème lié à la décision maintenant abandonnée de Gitpod d’utiliser Kubernetes.
Mais je ne suis pas pressé d’essayer un autre environnement de développement cloud avec Bencher à nouveau.
J’ai finalement porté la configuration de Gitpod vers un dev container
pour faciliter l’initiation des contributeurs.
Pour moi, je reste avec localhost.
Technologie
Verdict
Gitpod
❌
MacBook Pro M1
✅
Intégration Continue
Bencher est open source.
En tant que projet open source moderne, vous devez en quelque sorte être sur GitHub.
Cela signifie que le chemin de moindre résistance pour l’intégration continue (CI) est GitHub Actions.
Au fil des ans, j’ai commencé à détester les DSL CI basés sur YAML.
Chacun a ses propres particularités, et lorsqu’il s’agit d’une entreprise aussi grande que GitHub,
obtenir une icône ⚠️ au lieu d’une icône ❌ peut traîner pendant des années.
Cela m’a motivé à essayer Dagger.
À l’époque, vous ne pouviez utiliser Dagger qu’à travers ce langage ésotérique appelé CUE.
J’ai essayé. J’ai vraiment essayé. Pendant tout un week-end.
Peut-être que si ChatGPT avait existé à ce moment-là, j’aurais pu y arriver.
Mais je n’étais pas seul.
Dagger a finalement abandonné CUE complètement au profit de SDK plus raisonnables.
À ce moment-là, cependant, il était déjà trop tard pour moi.
Vaincu par Dagger, j’ai accepté mon destin de DSL CI YAML,
et Bencher utilise désormais GitHub Actions.
Bon sang, j’ai même construit une Action GitHub pour le Bencher CLI.
Soyez le changement problème que vous souhaitez voir dans le monde.
Technologie
Verdict
Dagger
❌
GitHub Actions
⚠️
Conclusion
Construire Bencher m’a beaucoup appris sur les compromis
associés à chaque décision d’ingénierie.
Il y a certains choix que je ferais différemment maintenant,
mais c’est une bonne chose.
Cela signifie que j’ai appris quelques trucs en cours de route.
Dans l’ensemble, je suis très satisfait de l’endroit où Bencher se trouve aujourd’hui.
Bencher est passé d’un croquis dans mon carnet à un produit à part entière
avec une base d’utilisateurs croissante, une communauté dynamique et des clients payants.
Je suis impatient de voir où nous mèneront les trois prochaines années !
Bencher est une suite d’outils de benchmarking continu.
Avez-vous déjà eu une régression de performance qui a impacté vos utilisateurs ?
Bencher aurait pu empêcher cela de se produire.
Bencher vous permet de détecter et de prévenir les régressions de performance avant qu’elles n’arrivent en production.
Exécuter: Exécutez vos benchmarks localement ou en CI en utilisant vos outils de benchmarking préférés. La CLI bencher enveloppe simplement votre harnais de benchmarking existant et stocke ses résultats.
Suivre: Suivez les résultats de vos benchmarks au fil du temps. Surveillez, interrogez et graphiquez les résultats à l’aide de la console web Bencher en fonction de la branche source, du banc d’essai et de la mesure.
Détecter: Détectez les régressions de performances en CI. Bencher utilise des analyses de pointe et personnalisables pour détecter les régressions de performances avant qu’elles n’arrivent en production.
Pour les mêmes raisons que les tests unitaires sont exécutés en CI pour prévenir les régressions de fonctionnalités, les benchmarks devraient être exécutés en CI avec Bencher pour prévenir les régressions de performance. Les bugs de performance sont des bugs !
🤖 Ce document a été automatiquement généré par OpenAI GPT-4. Il peut ne pas être précis et peut contenir des erreurs. Si vous trouvez des erreurs, veuillez ouvrir une issue sur GitHub.
