Lovable traslada las actualizaciones a su propio servidor y reduce el volumen de datos en torno al 97 %

Se añade un campo interno al documento de un proyecto y el navegador del usuario ya puede recibirlo. Lovable corría ese riesgo mientras su frontend se suscribía directamente a los documentos de Firestore. Los desarrolladores tenían que pensar en la API pública incluso al hacer un cambio corriente en la estructura de la base de datos. Además, los permisos de acceso debían mantenerse coherentes en dos lugares: las reglas de Firestore y el código de servidor en Go.

El equipo trasladó las actualizaciones a su propio servicio, Lovable Realtime. Ahora el servidor decide qué campos enviar a cada usuario y revisa esa decisión cuando cambian los datos o los permisos. Según Lovable, el servicio soportó un pico de 2,06 millones de suscripciones simultáneas. El interés práctico está en cómo se diseñan las suscripciones, cómo se verifican los permisos y cómo se migró un producto en funcionamiento.

Qué ocurre tras revocar el acceso

Imagine el espacio de trabajo de una empresa. Un empleado abrió un proyecto y luego un administrador lo excluyó del grupo con acceso. La pestaña ya abierta debe dejar de recibir actualizaciones. Cuando cambia el conjunto de permisos, el servidor también puede necesitar quitar campos concretos de las respuestas siguientes.

En Lovable, la comprobación de acceso se convirtió en una fuente de datos rastreable, igual que el propio proyecto. La suscripción depende tanto del contenido del proyecto como de los permisos del usuario. El cambio en cualquiera de esas dependencias obliga al servidor a recalcular el resultado disponible para el usuario. Al revocar el acceso, el flujo debe cerrarse en mitad de la sesión.

Esto resultó especialmente útil para los grupos corporativos: la información necesaria estaba en bases de datos distintas, Firestore y Spanner. Las reglas de seguridad de Firestore no podían leer Spanner. Una capa de servidor propia permitió combinar datos de ambas bases en una sola respuesta y aplicar el sistema común de permisos de la API.

Sin embargo, esta solución tiene un coste. Al principio, cualquier cambio en el documento del proyecto desencadenaba un recálculo completo de permisos, incluida la edición normal de archivos. El equipo dejó el recálculo solo para los cambios en los campos que intervienen en la decisión de acceso. Según sus datos, el número de recálculos bajó en torno al 84 %. La lista de esos campos hay que mantenerla como parte de la lógica de autorización; una comprobación estática independiente ayuda a detectar omisiones en los paquetes que cubre.

Cómo llegan las actualizaciones al navegador

Cada pestaña usa una conexión WebSocket, dentro de la cual funcionan varias suscripciones. Los cambios de Firestore y Spanner llegan mediante un mecanismo de captura de cambios a un puente y después a NATS. El servicio en Go recibe el evento y recalcula las suscripciones afectadas.

A continuación compara el hash del nuevo resultado con el anterior. Si para el usuario no ha cambiado nada, no hay nada que enviar. Si ha cambiado, puede transmitirse solo la diferencia. Varios componentes de la interfaz con la misma suscripción comparten automáticamente una única suscripción en el servidor.

Al reconectarse, el navegador envía una huella del estado guardado. El servidor vuelve a comprobar los permisos y carga los datos actuales. Si el resultado coincide, confirma que se puede usar la caché sin retransmitir todo el contenido.

En los 30 días indicados en el artículo, el servicio entregó 2.610 millones de tramas con datos y cambios. El equipo estimó en 40 TB la transmisión hipotética de cada resultado calculado completo. El volumen realmente transmitido fue de 1,11 TB gracias a la supresión de repeticiones, el envío de diferencias y la reutilización del estado al reconectarse. De ahí la estimación de una reducción de en torno al 97 %. Es una comparación con una base calculada de respuestas completas, no una reducción medida de los costes de Firestore.

Qué llevarse a tu propio producto

El cambio comenzó en modo sombra: el navegador se suscribía al nuevo servicio, pero seguía mostrando datos de Firestore. Así el equipo descubrió oleadas de reconexiones tras los despliegues, errores de clasificación de fallos y un límite de tamaño de respuesta demasiado pequeño. Después la proporción de usuarios se fue aumentando por etapas. Según Lovable, la migración se hizo sin incidentes para los usuarios.

Para la operación importa otro detalle: añadir servidores no alivia las conexiones largas ya establecidas. Por eso Lovable limita el número de conexiones por instancia del servicio, mantiene un margen de memoria y reparte en el tiempo las reconexiones tras un despliegue.

No todos los equipos necesitarán construir un sistema así desde cero. Aquí la elección la determinaron las bases de datos existentes, el backend en Go y el requisito de cambiar permisos durante la sesión. Pero puedes revisar tu propio producto ya: qué campos llegan al navegador, qué pasa tras revocar el acceso y si el servidor aguanta el regreso simultáneo de muchas pestañas.