Lovable crée un service en temps réel pour centraliser les autorisations d’accès aux données

Lovable a indiqué le 9 novembre 2026 que son interface côté client avait abandonné Firestore après le déploiement complet de Lovable Realtime, un service personnalisé qui centralise l’autorisation et qui a atteint un pic de 2,06 millions de souscriptions simultanées au cours d’une période de mesure de 30 jours.

Cette migration confie à l’API Go de Lovable les décisions concernant les droits d’accès et les champs visibles. Pour la plateforme de l’entreprise dédiée à la création d’applications d’IA, le service permet de combiner les données de Firestore et de Spanner, puis de mettre à jour la vue d’un utilisateur lorsque les informations sous-jacentes ou ses autorisations changent.

Centralisation des autorisations et des données en temps réel

Certaines parties de Lovable utilisaient auparavant Firestore dans le navigateur onSnapshot pour recevoir les mises à jour. Le navigateur recevait des documents entiers, tandis que les règles de Firestore devaient reproduire le modèle d’autorisations de l’API Go. Cette conception faisait aussi des changements courants apportés aux documents une source de risque d’exposition : une personne qui ajoutait un champ pouvait déterminer quelles données parvenaient aux navigateurs des utilisateurs sans nécessairement en mesurer les conséquences.

Les règles de Firestore peuvent interroger les données de Firebase, mais pas celles de Spanner, ce qui complique les mises à jour des autorisations touchant de grands groupes d’entreprise synchronisés par SCIM, un protocole qui synchronise les utilisateurs et les groupes avec un espace de travail Lovable. Pour les clients professionnels et les grandes entreprises, un proxy temporaire passant par l’API Go réutilisait les vérifications d’autorisations de l’API. Il ouvrait également des écouteurs Firestore en amont distincts pour les dépendances de chaque client, ce qui multipliait les flux et consommait les ressources d’un pool de connexions partagé avec les requêtes ordinaires à la base de données.

Lovable exigeait que la solution de remplacement fonctionne avec les deux bases de données existantes, réévalue continuellement les droits d’accès et interrompe le flux d’un utilisateur dont les autorisations avaient été révoquées en cours de session. L’entreprise voulait également que les champs non autorisés soient retenus avant que les données ne quittent le serveur. Selon son évaluation, les solutions de transport, de synchronisation et d’intégration aux bases de données qu’elle avait examinées ne répondaient pas à ces exigences combinées sans nécessiter d’importants travaux d’intégration, un changement de base de données ou une réplication dans Postgres.

Le service Go ainsi créé fonctionne sur GKE et ouvre une connexion WebSocket par onglet de navigateur, les abonnements étant multiplexés sur cette connexion. Des flux de capture des modifications acheminent celles de Firestore et de Spanner par un pont vers NATS, le bus de messages du service. Les abonnements correspondants recalculent leurs vues, comparent les empreintes xxh3-128 et n’envoient des différences que lorsque le résultat change. Un même abonnement peut puiser dans les deux bases de données tout en appliquant le cadre d’autorisations de l’API.

Les autorisations sont traitées comme une autre source de données réactive, ce qui permet aux changements de droits d’accès de déclencher de nouveaux résultats indépendamment des modifications ordinaires des documents. Lovable a indiqué que le fait de ne recalculer les autorisations que lorsque les champs concernés par les décisions d’accès changeaient, plutôt qu’à chaque mise à jour pertinente d’un document, avait réduit ces recalculs d’environ 84 %. Le service compte environ 40 types d’abonnement gérés par sept équipes, avec des interfaces typées, des abonnements partagés côté serveur et des alertes acheminées vers les équipes concernées.

Le trafic en mode miroir a permis de valider le déploiement

Lovable a d’abord exécuté le service en mode miroir : l’interface frontend suivait l’intégralité du nouveau parcours, mais écartait les charges utiles et continuait à afficher les données de Firestore. L’utilisation du trafic réel et de structures de données réelles a révélé des vagues de reconnexions après les déploiements, des erreurs mal classées et une limite de taille des charges utiles trop basse pour les données réelles. Un indicateur de fonctionnalité a ensuite permis d’augmenter la disponibilité du service auprès de 1 %, puis de 10 %, 50 % et 100 % des utilisateurs sur plusieurs jours. Lovable a déclaré que le déploiement n’avait entraîné ni incident visible par les utilisateurs ni régression des indicateurs surveillés.

Comme les connexions WebSocket sont persistantes et peuvent durer des heures, l’ajout de pods ne suffit pas à lui seul à redistribuer la charge existante. Lovable répartit la charge en fonction du nombre de connexions, et adapte la capacité en tenant compte de ce nombre ainsi que de l’utilisation du processeur et de la mémoire. L’entreprise limite aussi le nombre de connexions par pod afin de réduire les vagues de reconnexions. Après s’être reconnectés, les clients envoient une empreinte de leur état mis en cache ; le serveur peut ainsi confirmer, après avoir revérifié les autorisations, que les données n’ont pas changé, plutôt que de les transmettre à nouveau.

L’auteur de l’article a indiqué que la réalisation du cœur du service avait nécessité 40 journées de travail effectif et que les agents de codage s’étaient chargés de la majeure partie de l’implémentation, une fois l’architecture et les cas limites définis. Un banc d’intégration associait des émulateurs Firestore, Auth et Spanner à un serveur NATS intégré ainsi qu’à de véritables jetons d’identification générés par les émulateurs, permettant aux agents de tester les modifications sur l’ensemble de la pile.

Résultats en production et prise en charge potentielle des applications

Pour la période du 5 septembre au 5 octobre 2026, Lovable a fait état de 2,61 milliards de trames de données et de correctifs, hors trames de contrôle reprises, et estimé que l’envoi d’instantanés complets pour chaque résultat calculé aurait généré 40 To de charges utiles applicatives. La déduplication, les différences et la réutilisation lors des reconnexions ont ramené le volume réel des charges utiles envoyées à 1,11 To, soit une réduction estimée de 97 % par rapport à ce niveau de référence. Ces chiffres excluent la surcharge liée au protocole et au transport.

Lovable a mesuré à 66 millisecondes au p50 et à 249 millisecondes au p99 le délai entre l’écriture dans une base de données source et la disponibilité d’une trame sortante prête à être envoyée. Ces mesures excluent l’écriture sur la socket, le temps de transit sur le réseau et le traitement côté client ; elles ne représentent donc pas le délai complet d’une mise à jour tel qu’il est perçu par l’utilisateur.

Lovable a indiqué qu’elle ajoutait activement des primitives d’événements de domaine pour les cas où les consommateurs doivent être informés qu’un événement s’est produit plutôt que de recevoir un instantané des données, et que le service pourrait par la suite devenir une fonctionnalité intégrée aux applications créées avec Lovable. Une telle extension apporterait aux applications conçues par les clients des autorisations contrôlées par le backend et des vues en temps réel. Le déploiement actuel fournit déjà aux équipes de Lovable une base commune pour une collaboration plus poussée, à mesure que leur infrastructure de données évolue.