Lovable crea un servicio en tiempo real para centralizar los permisos de datos

Lovable informó el 9 de noviembre de 2026 que su frontend había dejado de usar Firestore tras el despliegue completo de Lovable Realtime, un servicio personalizado que centraliza la autorización y alcanzó un máximo de 2,06 millones de suscripciones simultáneas durante un período de medición de 30 días.

La migración sitúa las decisiones sobre el acceso y los campos visibles en el backend de Go de Lovable. Para la plataforma de la empresa que permite crear aplicaciones con IA, el servicio ofrece una forma de combinar datos de Firestore y Spanner, y actualizar la vista de un usuario cuando cambia la información subyacente o los permisos de ese usuario.

Centralización de permisos y datos en tiempo real

Algunas partes de Lovable utilizaban anteriormente Firestore del lado del navegador onSnapshot para recibir actualizaciones. El navegador recibía documentos completos, mientras que las reglas de Firestore debían reflejar el modelo de permisos de la API de Go. Además, con este diseño la exposición de datos dependía de cambios rutinarios en los documentos: alguien que añadiera un campo podía determinar qué información llegaba a los navegadores de los usuarios sin necesariamente darse cuenta de esa consecuencia.

Las reglas de Firestore pueden consultar datos de Firebase, pero no de Spanner, lo que suponía un obstáculo para actualizar la autorización de grandes grupos empresariales sincronizados mediante SCIM, que sincroniza usuarios y grupos con un espacio de trabajo de Lovable. Un proxy temporal a través de la API de Go para clientes empresariales y corporativos reutilizaba las comprobaciones de permisos de la API. También abría escuchas independientes de Firestore en el servidor de origen para las dependencias de cada cliente, lo que duplicaba flujos y consumía capacidad de un grupo de conexiones compartido con las solicitudes habituales a la base de datos.

Lovable exigía que la solución sustituta funcionara con ambas bases de datos existentes, reevaluara el acceso continuamente y cerrara el flujo de un usuario revocado en mitad de la sesión. También quería que los campos no autorizados se retuvieran antes de que cualquier dato saliera del servidor. La empresa concluyó que las opciones de transporte, sincronización e integración con bases de datos que evaluó no ofrecían esa combinación sin un trabajo de integración considerable, un cambio de base de datos o la replicación de los datos en Postgres.

El servicio de Go resultante se ejecuta en GKE y abre un WebSocket por pestaña del navegador, con las suscripciones multiplexadas a través de esa conexión. Los flujos de captura de cambios de datos transportan los cambios de Firestore y Spanner mediante un puente hasta NATS, el bus de mensajes del servicio. Las suscripciones coincidentes vuelven a calcular sus vistas, comparan hashes xxh3-128 y envían deltas solo cuando cambia el resultado. Una única suscripción puede obtener datos de ambas bases de datos y aplicar al mismo tiempo el marco de permisos de la API.

La autorización se trata como otra fuente de datos reactiva, lo que permite que los cambios de permisos generen resultados nuevos independientemente de las ediciones habituales de documentos. Lovable informó que volver a calcular los permisos solo cuando cambiaban los campos implicados en las decisiones de acceso, en lugar de hacerlo con cada actualización pertinente de un documento, redujo esos recálculos alrededor de un 84 %. El servicio cuenta con aproximadamente 40 tipos de suscripción, gestionados por siete equipos, con interfaces tipadas, suscripciones compartidas en el servidor y alertas dirigidas a los equipos correspondientes.

El tráfico en sombra validó la implementación

Lovable primero ejecutó el servicio en modo sombra: el frontend recorría toda la nueva ruta, pero descartaba las cargas útiles y seguía mostrando los datos de Firestore. El uso de tráfico real y estructuras de datos reales dejó al descubierto oleadas de reconexiones tras las implementaciones, errores mal clasificados y un límite de carga útil demasiado bajo para los datos reales. Después, una bandera de funcionalidad elevó la disponibilidad del 1 % al 10 %, al 50 % y al 100 % de los usuarios durante varios días. Lovable afirmó que la implementación no provocó ningún incidente visible para los usuarios ni regresiones en las métricas supervisadas.

Como las conexiones WebSocket son persistentes y pueden durar horas, añadir pods no redistribuye por sí solo la carga existente. Lovable distribuye la carga en función del número de conexiones, escala teniendo en cuenta tanto las conexiones como la CPU y la memoria, y limita las conexiones por pod para reducir las oleadas de reconexión. Tras reconectarse, los clientes envían una huella digital de su estado en caché, lo que permite al servidor confirmar, después de volver a comprobar la autorización, que los datos no han cambiado, en vez de transmitirlos de nuevo.

El autor de la publicación afirmó que el núcleo requirió 40 jornadas de trabajo práctico y que los agentes de programación se encargaron de la mayor parte de la implementación una vez definidos la arquitectura y los casos límite. Un equipo de integración combinó emuladores de Firestore, Auth y Spanner con un servidor NATS integrado y tokens de ID reales generados por emuladores, lo que permitió a los agentes probar cambios en toda la pila.

Resultados en producción y posible compatibilidad con aplicaciones

Para el período comprendido entre el 5 de septiembre y el 5 de octubre de 2026, Lovable informó de 2,61 mil millones de tramas de datos y de parches, sin contar las tramas de control reanudadas, y estimó que las instantáneas completas de cada resultado calculado habrían generado 40 TB de carga útil de la aplicación. La deduplicación, los deltas y la reutilización en las reconexiones redujeron la carga útil enviada efectivamente a 1,11 TB, una reducción estimada del 97 % respecto de ese valor de referencia. Las cifras de carga útil no incluyen la sobrecarga del protocolo ni del transporte.

Lovable midió en 66 milisegundos en p50 y 249 milisegundos en p99 el intervalo entre una escritura en la base de datos de origen y el momento en que una trama saliente estaba lista para enviarse. Esas mediciones excluyen las escrituras en el socket, el tiempo de red y el procesamiento del cliente, por lo que no representan el tiempo total de actualización percibido por el usuario.

Lovable señaló que está añadiendo activamente primitivas de eventos de dominio para los casos en que los consumidores necesitan recibir un aviso de que algo ha ocurrido, en lugar de una instantánea de datos, y que el servicio podría convertirse más adelante en una funcionalidad integrada en las aplicaciones creadas con Lovable. Una ampliación así llevaría permisos controlados desde el backend y vistas en tiempo real a las aplicaciones creadas por los clientes. La implementación actual ya ofrece a los equipos de Lovable una base compartida para una colaboración más enriquecedora, a medida que evoluciona su infraestructura de datos.