4 articles associés au mot-clé « SQLite »

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.

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.

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.