Bynle

Client

React, avec React Router protégeant les routes privées et un arbre de routes distinct pour les comptes scanneur.

Application

Vues REST Django regroupées en dix gestionnaires de domaine, avec des sérialiseurs pour la validation et la conversion JSON.

Données

PostgreSQL pour les données structurées, exécuté depuis une image Docker ; un bucket S3 pour les fichiers téléversés.

Intégration

Stripe pour les paiements et l’inscription à Connect, avec une vérification d’état décidant si un club ou un utilisateur peut encaisser.

Déploiement

Railway pour le backend et la base, AWS Amplify pour le frontend, gestion de versions Git pour les deux.

Les tests ont suivi trois pistes : relecture de code sur chaque merge request, tests unitaires du backend, et sessions de test avec de vrais étudiants.

Le backend a terminé avec 134 tests unitaires sur les modèles et les vues : intégrité des données et règles de validation d’un côté, traitement des requêtes et logique métier de l’autre, y compris des contrôles de permission comme vérifier que seul un compte scanneur peut atteindre le point de validation des billets. Aucune modification n’a rejoint la branche principale sans relecture par l’autre.

Les tests utilisateurs ont changé le produit. Deux demandes sont revenues assez nettement pour que nous les construisions :

• Une cloche de notification. Les utilisateurs voulaient atteindre les demandes d’amitié et les transferts entrants depuis n’importe où, plutôt qu’en naviguant jusqu’à la page qui les contenait. Une cloche est apparue dans la barre de navigation, avec un compteur.
• Supprimer un transfert envoyé. Les participants voulaient retirer un transfert envoyé par erreur ou après un changement d’avis. Les transferts envoyés sont devenus supprimables.

Ce qui a cassé

1. 01

   Les responsables de club modélisés en classe dédiée

   Problème

   Les responsables de club ont d’abord été une classe de modèle à part entière. C’était la mauvaise forme : la relation entre utilisateurs et clubs est de plusieurs à plusieurs, et la forcer dans une classe dédiée rendait l’administration pénible.

   Correctif

   Refonte en relation plusieurs-à-plusieurs, ce qui a permis à plusieurs utilisateurs d’administrer plusieurs clubs sans cérémonie et a simplifié tout le parcours d’administration.

2. 02

   Deux personnes, des migrations supprimées, une base cassée

   Problème

   Au début, nous travaillions chacun sur une branche et générions tous les deux des migrations en modifiant les modèles. Aucun de nous ne maîtrisait assez les migrations Django, et nous en avions tous les deux supprimé. Au rebase pour fusionner dans main, la base a cassé : elle ne correspondait plus aux modèles, et il nous a fallu longtemps pour comprendre pourquoi.

   Correctif

   Nous avons convenu de ne plus jamais supprimer une migration, sauf base sauvegardée et remise à zéro réellement justifiée. Un script qui repeuplait la base depuis zéro nous a permis de reconstruire un jeu de données fonctionnel pendant que nous démêlions cela.

3. 03

   Les billets restaient valides pendant le transfert

   Problème

   Tant qu’un transfert était en cours, le billet restait actif, avec un risque d’entrée non autorisée sur un billet déjà en train d’être cédé.

   Correctif

   Les billets conservent un état de transfert jusqu’à l’acceptation du destinataire ou l’annulation par l’expéditeur. Dans cet état, le billet ne peut pas être scanné et compte comme invalide à l’entrée.

4. 04

   Déployer trois pièces mobiles

   Problème

   Déployer ensemble le backend Django, le frontend React et la base a demandé des jours de documentation et une longue série de tentatives ratées sur le serveur backend.

   Correctif

   Railway, qui s’intègre au dépôt et récupère la dernière version d’une branche fixe, a mis le backend et la base en ligne dans une instance partagée ; le frontend est parti sur AWS Amplify.