Lovable a transféré les mises à jour sur son propre serveur et réduit le volume de données d’environ 97%

Il suffisait d’ajouter un champ interne à un document de projet pour que le navigateur de l’utilisateur puisse le recevoir. Lovable était exposé à ce risque tant que le frontend s’abonnait directement aux documents Firestore. Les développeurs devaient tenir compte de l’API publique même lors d’une simple modification de la structure de la base. Il fallait aussi maintenir des droits d’accès cohérents à deux endroits : dans les règles Firestore et dans le code serveur en Go.

L’équipe a transféré les mises à jour vers son propre service, Lovable Realtime. Le serveur détermine désormais quels champs envoyer à chaque utilisateur et réévalue cette décision lorsque les données ou les autorisations changent. Selon Lovable, le service a supporté un pic de 2,06 millions d’abonnements simultanés. L’intérêt pratique réside ici dans l’architecture des abonnements, le contrôle des droits et la méthode de migration d’un produit en production.

Que se passe-t-il après la révocation d’un accès ?

Imaginez l’espace de travail d’une entreprise. Un salarié ouvre un projet, puis un administrateur le retire du groupe autorisé à y accéder. L’onglet déjà ouvert doit cesser de recevoir les mises à jour. Lorsque les autorisations changent, le serveur peut aussi devoir retirer certains champs des réponses suivantes.

Chez Lovable, le contrôle d’accès est devenu une source de données surveillée au même titre que le projet lui-même. Un abonnement dépend à la fois du contenu du projet et des autorisations de l’utilisateur. Toute modification de l’une de ces dépendances oblige le serveur à recalculer le résultat accessible à cet utilisateur. Si l’accès est révoqué, le flux doit se fermer en cours de session.

Cette approche s’est révélée particulièrement utile pour les groupes d’entreprise : les informations nécessaires étaient réparties entre deux bases, Firestore et Spanner. Les règles de sécurité Firestore ne pouvaient pas lire Spanner. Une couche serveur propre à Lovable a permis de réunir les données des deux bases dans une même réponse et d’appliquer le système commun d’autorisations de l’API.

Cette solution a toutefois un coût. Au départ, toute modification du document de projet déclenchait une réévaluation complète des droits, y compris une simple modification de fichier. L’équipe a limité cette réévaluation aux changements touchant les champs qui interviennent dans la décision d’accès. Selon elle, le nombre de réévaluations a diminué d’environ 84%. La liste de ces champs doit être maintenue comme un élément de la logique d’autorisation ; une vérification statique distincte aide à repérer les oublis dans les packages qu’elle couvre.

Comment les mises à jour arrivent dans le navigateur

Chaque onglet utilise une seule connexion WebSocket, qui transporte plusieurs abonnements. Les modifications de Firestore et de Spanner passent par un mécanisme de capture des changements, puis par une passerelle, avant d’arriver dans NATS. Le service en Go reçoit l’événement et recalcule les abonnements concernés.

Il compare ensuite le hachage du nouveau résultat à celui du précédent. Si rien n’a changé pour l’utilisateur, il n’y a rien à envoyer. Sinon, il peut transmettre uniquement la différence. Plusieurs composants d’interface ayant le même abonnement partagent automatiquement un seul abonnement côté serveur.

Lors d’une reconnexion, le navigateur envoie une empreinte de l’état conservé. Le serveur vérifie de nouveau les droits et charge les données à jour. Si le résultat correspond, il confirme que le cache peut être utilisé sans retransmettre l’ensemble du contenu.

Sur les 30 jours mentionnés dans l’article, le service a livré 2,61 milliards de trames contenant des données et des modifications. L’équipe a estimé à 40 To le volume qu’aurait représenté l’envoi intégral de chaque résultat calculé. Le volume réellement transmis s’est établi à 1,11 To grâce à la suppression des doublons, à l’envoi des différences et à la réutilisation de l’état lors des reconnexions. D’où une réduction estimée à environ 97%. Il s’agit d’une comparaison avec un volume théorique de réponses complètes, et non d’une baisse mesurée des dépenses Firestore.

Ce que vous pouvez appliquer à votre produit

La migration a commencé en mode miroir : le navigateur s’abonnait au nouveau service, mais continuait d’afficher les données de Firestore. L’équipe a ainsi détecté des vagues de reconnexions après les déploiements, des erreurs de classification des défaillances et une limite de taille des réponses trop basse. La proportion d’utilisateurs concernés a ensuite augmenté par paliers. Selon Lovable, la migration s’est déroulée sans incident affectant les utilisateurs.

Un autre détail compte en exploitation : ajouter des serveurs ne soulage pas les connexions de longue durée déjà établies. Lovable limite donc le nombre de connexions par instance du service, conserve une marge de mémoire et étale les reconnexions dans le temps après un déploiement.

Toutes les équipes n’auront pas besoin de construire un tel système de zéro. Ici, le choix a été dicté par les bases existantes, le backend en Go et la nécessité de prendre en compte les changements de droits en cours de session. Mais chacun peut dès maintenant examiner son propre produit : quels champs sont envoyés au navigateur, que se passe-t-il après la révocation d’un accès et le serveur supporte-t-il la reconnexion simultanée d’un grand nombre d’onglets ?