10 articles associés au mot-clé « Fondations »

Pour Curling IO v3, nous savions que nous voulions quitter la pile Ruby on Rails utilisée pour la version 2. Nous voulions un langage à typage statique avec de meilleures garanties à la compilation et moins de pièges. Nous avons d’abord exploré Gleam, qui répondait à ces critères et nous donnait accès à la BEAM. Lustre offrait un cadre d’interface typé pour le serveur et le client. Une première mise en œuvre nous a permis de voir comment cette combinaison s’intégrerait à notre architecture. Nos premiers articles sur les fondations décrivent ce que nous apprenions et construisions.

Ce travail a aidé à préciser les besoins du produit, les changements souhaités par rapport à la version 2 et la conception de l’interface. Il a aussi révélé des compromis de déploiement et d’interactions côté client qui nous ont finalement amenés à choisir Rust et TypeScript pour notre architecture, avant d’aller plus loin avec Gleam et Lustre. SQLite et la conception du produit ont été conservés. Nous avons depuis porté et enrichi nos outils SQL et construit un petit environnement d’exécution TypeScript appelé Hypertea pour les interactions côté client.

Ce changement a amélioré le déploiement, nous a donné une automatisation utile à la compilation et convenait à notre façon d’examiner et de corriger les problèmes. Malheureusement, il a aussi rendu nos compilations beaucoup plus lourdes. Il y a des aspects de Gleam et Lustre que nous préférons encore.

Curling IO fonctionnait auparavant sur Debian configuré avec Ansible. Cette installation marchait. Elle installait les paquets, configurait Caddy et le pare-feu, créait les services systemd et préparait nos emplacements de déploiement bleu-vert.

Le problème venait du fait qu’un serveur fonctionnel et modifiable nous permettait de conserver une description incomplète. Ansible pouvait décrire le serveur, mais d’anciens fichiers restaient sous /etc. Des outils de compilation avaient été installés autrement. Les choix du fournisseur sur les disques et le RAID existaient en dehors du playbook. Un provisionnement pouvait réussir parce qu’une exécution antérieure avait déjà laissé le bon élément en place.

NixOS tolère beaucoup moins ces lacunes. Cette rigueur est parfois agaçante, mais constitue aussi son principal avantage. Elle nous oblige à décider qui est responsable d’un fichier, d’un service, d’un secret, d’un paquet ou d’un élément nécessaire à la récupération.

Le passage d’Ansible à NixOS nous a montré combien de validations et de nettoyages manquaient à l’ancienne approche. Il a exposé la différence entre un serveur qui continue de fonctionner et un serveur qu’on peut recréer à partir d’éléments déclarés.

Voici ce que nous avons trouvé utile en reconstruisant un serveur physique OVH à partir de disques vides, en restaurant son état et en rendant le processus assez sûr pour être répété.

Le panneau d’administration de Curling IO devrait réagir instantanément lorsqu’un gestionnaire prépare une saison. Activer un paramètre, enregistrer un rabais, passer d’une section de produit à l’autre : la page devrait répondre sans rechargement complet.

La version 2 fonctionne, mais chaque envoi de formulaire recharge la page. L’administration de la version 3 est un seul composant serveur Lustre sur BEAM : une connexion WebSocket et un processus Erlang de longue durée par session. Chaque interaction passe par ce WebSocket et revient sous forme de modification du DOM. La page ne se recharge jamais, sans cadriciel JavaScript côté client.

En écrivant l’article précédent sur nos bases SQLite par test, je décrivais comment chaque test reçoit sa propre base en mémoire, sans connexion ni état partagé. Une idée m’est venue : si rien n’est partagé, pouvons-nous simplement tous les exécuter en même temps?

Nous pouvions, et notre suite de tests serveur est passée d’environ 4 secondes à environ 0,85 seconde pour quelque 800 tests. Aucun changement dans les tests eux-mêmes. Un seul module Erlang de 25 lignes.

Les tests de Curling IO n’ont besoin ni d’une base de données de test partagée, ni de fonctions de nettoyage, ni d’astuces transactionnelles. Chaque test a sa propre base de données. Il peut donc réussir seul ou dans la suite complète pour la même raison : rien d’autre ne peut toucher ses données.

Cela découle d’un choix de la version 3 : SQLite fonctionne dans le processus de l’application. Chaque test obtient une base SQLite en mémoire complètement indépendante, clonée depuis un modèle en quelques microsecondes avec l’API de sauvegarde de SQLite.

La version 3 devrait coûter moins cher à exploiter, être plus facile à restaurer et rester rapide aux pointes d’inscription et de pointage en direct. Ces objectifs nous ont menés à un choix inattendu : SQLite.

Au départ, nous pensions utiliser PostgreSQL. Après dix ans à exploiter Postgres en production, nous connaissions les outils, les modes de défaillance et les procédures d’exploitation. Puis nous avons comparé Postgres autohébergé à SQLite avec Litestream, et changé d’avis.

Lorsqu’un curleur demande un courriel de connexion, la page devrait répondre immédiatement. Il ne devrait pas attendre Postmark, et nous ne devrions pas exploiter un parc de processus de travail distincts simplement pour envoyer un message en arrière-plan.

Curling IO version 3 exécute les tâches en arrière-plan dans le même environnement BEAM que l’application web. Sans Redis, processus de travail distinct ou déploiement supplémentaire. La file d’attente est durable, car les tâches en attente sont stockées dans SQLite plutôt qu’en mémoire.

Curling IO fonctionne sans mot de passe depuis la version 2. Aucun mot de passe à retenir ou à voler, aucun parcours de réinitialisation. Vous entrez votre adresse courriel, nous vous envoyons un code de connexion de courte durée et vous êtes connecté. Cette approche fonctionne bien depuis plus de dix ans. Pour la version 3, nous la conservons tout en corrigeant certains irritants et en ajoutant la prise en charge de plusieurs adresses courriel.

Mais parlons d’abord des raisons de cette décision controversée.

La prise en charge de l’anglais et du français doit aller de soi. Un club québécois ne devrait pas tomber sur une page d’inscription à moitié traduite, et une organisation qui organise des compétitions nationales ne devrait pas avoir à ouvrir une demande de soutien pour signaler un libellé manquant.

Curling IO est bilingue depuis la version 2. Mais après dix ans à maintenir environ 10 000 clés de traduction YAML, nous avons atteint les limites de cette approche : des clés ou des traductions manquantes passent inaperçues, et des clés inutilisées s’accumulent sans qu’on s’en aperçoive. La version 3 conserve l’expérience bilingue et empêche davantage de ces erreurs d’être mises en production.

La prochaine version de Curling IO devrait vous sembler familière : les mêmes inscriptions, horaires, pointages et tâches d’administration du club, avec plus de rapidité et moins de risques de panne. Le travail se fait surtout sous le capot, mais les avantages sont concrets : moins de ralentissements aux pointes d’inscription, une meilleure fiabilité pendant les événements en direct et une plateforme que nous pourrons continuer d’améliorer longtemps.

Cette série explique ce qui change, ce qui reste et pourquoi nous faisons ce pari.