Firebase est une merveilleuse façon de démarrer. C'est un endroit difficile pour grandir. Les éléments mêmes qui le rendent rapide au premier jour, des documents sans schema, un système d'authentification fermé, des requêtes qui masquent leur coût, deviennent ceux qui vous combattent une fois que le produit se complexifie et que les données deviennent relationnelles.

Nous avons reconstruit une plateforme de collecte de fonds qu'il ne suffisait plus à porter. La nouvelle fondation, c'était PostgreSQL avec Prisma pour les données et une bibliothèque d'authentification moderne pour les comptes. La contrainte qui a rendu le projet intéressant était simple. L'ancienne application avait de vrais utilisateurs qu'on ne pouvait pas déconnecter, et de vrais enregistrements qu'on ne pouvait pas perdre. Le sol devait bouger pendant que les gens se tenaient dessus.

Vous ne migrez pas des données, vous migrez de la confiance

Il est facile de présenter une migration comme un déplacement de lignes de A vers B. Les lignes sont la partie facile. La partie difficile, c'est que chaque utilisateur a un compte, un mot de passe, une session et l'attente que rien de tout cela ne casse. Perdez un enregistrement et vous avez un bug. Déconnectez tout le monde, ou pire, verrouillez quelqu'un dehors, et vous avez perdu sa confiance sur une plateforme qui en dépend entièrement.

Nous avons donc traité les comptes comme la partie la plus à risque du déplacement, et non comme une réflexion de dernière minute. Le plan devait permettre à un utilisateur existant de se connecter avec ses identifiants existants sur le nouveau système, sans e-mail de réinitialisation, sans friction, sans le moindre signe que quelque chose avait changé sous ses pieds.

Déplacer les données, c'est un script. Déplacer les comptes sans que personne ne s'en aperçoive, c'est ça, le vrai projet.

Faire suivre l'ancienne identité

La technique qui fait fonctionner tout cela consiste à garder un fil tendu vers l'ancien monde sur chaque enregistrement. À mesure que nous transférions les données, chaque ligne migrée se souvenait de son identifiant d'origine dans l'ancien système. C'est cette correspondance qui permet à la nouvelle application de reconnaître un ancien utilisateur et de réconcilier les deux mondes sans deviner.

L'authentification reçoit le même traitement. Nous marquons quels comptes ont été repris de l'ancien système et gérons leur première connexion de manière particulière, en validant les anciens identifiants et en les faisant passer discrètement dans le nouveau schéma. L'utilisateur tape le même mot de passe que d'habitude. Il n'apprend jamais que la mécanique derrière a été remplacée.

Migrer par phases, jamais d'un seul bond

Une bascule en big-bang, où l'on fait tout basculer à minuit en priant, c'est ainsi que les migrations deviennent des pannes. Nous l'évitons. Le modèle qui fonctionne consiste à faire tourner le nouveau système aux côtés de l'ancien, à déplacer les données par passes contrôlées, et à conserver la possibilité de vérifier chaque passe avant de lui faire confiance.

Cela veut dire écrire des migrations qu'on peut exécuter plusieurs fois sans danger, pour qu'une passe inachevée puisse être relancée sans créer de doublons. Cela veut dire vérifier les comptages et contrôler des enregistrements par sondage après chaque étape. Et cela veut dire garder l'ancien système consultable jusqu'à ce que le nouveau ait mérité le trafic, pour qu'il y ait toujours un endroit où regarder quand un chiffre ne correspond pas.

Le schema est une fonctionnalité, pas une taxe

Le bénéfice plus profond du déplacement, c'était le schema lui-même. Firestore vous laisse stocker n'importe quoi, ce qui ressemble à de la liberté jusqu'au moment où vous réalisez que personne ne peut dire quelle forme les données ont réellement. Passer à un véritable schema relationnel a forcé les questions repoussées depuis des années. Qu'est-ce qui est obligatoire, qu'est-ce qui est lié à quoi, qu'est-ce qui ne doit jamais arriver.

Ce travail n'est pas une charge inutile, c'est là que vont mourir bon nombre de bugs latents. Un schema que vous pouvez lire à voix haute est un schema sur lequel toute votre équipe peut raisonner. Les contraintes que la base impose désormais sont des règles que vous n'avez plus à penser à faire respecter à la main.

L'objectif ennuyeux est le bon objectif

Le critère de réussite d'une migration comme celle-ci, c'est que personne ne l'a remarquée. Aucun ticket de support sur des données perdues, aucune vague de réinitialisations de mot de passe, aucun trou mystérieux dans les enregistrements. L'ennui, c'est la victoire. On y arrive en traitant les comptes comme sacrés, en faisant suivre l'ancienne identité, en avançant par phases vérifiables et en se servant du nouveau schema pour rembourser une dette que l'on traînait depuis des années. Faites-le bien et la seule preuve que cela a eu lieu, c'est que tout est soudain devenu plus simple à construire.