Si votre club de curling cherche un logiciel de gestion ou se demande s’il est temps de remplacer celui qu’il utilise, un mauvais choix peut entraîner des années de solutions de contournement. Voici les critères à examiner.
Cet article présente notre exploration initiale de Gleam pour Curling IO v3. Nous avons finalement choisi Rust et TypeScript. Pourquoi nous avons choisi Rust pour la version 3 explique cette décision et ce que nous avons conservé de cette exploration.
Cette note d’architecture technique porte sur le choix de base de données pour Curling IO v3. Elle s’adresse aux ingénieurs logiciels et aux responsables de l’exploitation, et aborde SQLite, Litestream, l’isolation des bases de données, l’hébergement et les compromis de récupération plus en détail que nos articles habituels sur le produit.
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.
Les grandes compétitions de curling imposent des exigences très différentes à un logiciel de celles d’une soirée de ligue typique. Les inscriptions peuvent comporter des règles de qualification et la formation d’équipes. Les horaires de séances doivent couvrir plusieurs groupes et formats de séries. Le trafic des pointages en direct peut bondir lorsque des milliers de partisans suivent les mêmes parties.
Cet article présente notre exploration initiale de Gleam pour Curling IO v3. Nous avons finalement choisi Rust et TypeScript. Pourquoi nous avons choisi Rust pour la version 3 explique cette décision et ce que nous avons conservé de cette exploration.
Cette note technique d’implémentation vient du développement de Curling IO v3. Elle s’adresse aux ingénieurs logiciels et aborde Gleam, la BEAM, OTP, les files d’attente dans SQLite, la durabilité et l’exécution des tâches plus en détail que nos articles habituels sur le produit.
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.
Cet article présente notre exploration initiale de Gleam pour Curling IO v3. Nous avons finalement choisi Rust et TypeScript. Pourquoi nous avons choisi Rust pour la version 3 explique cette décision et ce que nous avons conservé de cette exploration.
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.
Cet article présente notre exploration initiale de Gleam pour Curling IO v3. Nous avons finalement choisi Rust et TypeScript. Pourquoi nous avons choisi Rust pour la version 3 explique cette décision et ce que nous avons conservé de cette exploration.
Cette note d’architecture technique porte sur la localisation dans Curling IO v3. Elle s’adresse aux ingénieurs logiciels et aborde Fluent, les vérifications de traduction à la compilation, la modélisation du contenu bilingue et le routage par langue plus en détail que nos articles habituels sur le produit.
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.
Cet article présente notre exploration initiale de Gleam pour Curling IO v3. Nous avons finalement choisi Rust et TypeScript. Pourquoi nous avons choisi Rust pour la version 3 explique cette décision et ce que nous avons conservé de cette exploration.
Cet aperçu porte sur les fondations techniques explorées pour Curling IO v3. Il s’adresse aux ingénieurs logiciels et aux autres personnes qui s’intéressent à l’architecture des applications. Il aborde Gleam, la BEAM, SQLite, l’hébergement et la mise à l’échelle plus en détail que nos articles habituels sur le produit.
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.