Desarrollo de un sistema de presencia con Bubble
Descripción del tutorial
Tutorial completo de implementación de un sistema de presencia en Bubble, utilizando únicamente elementos nativos de Bubble, sin integración de servicios externos. Este sistema representa un modelo resiliente para la monitorización de presencia en Bubble, combinando workflows recursivos, auto-reparables, y sincronización en tiempo real entre cliente y servidor.
Video tutorial
Resumen del tutorial
1. Descripción general del proyecto
Un sistema de monitoreo de presencia es una funcionalidad importante en muchas aplicaciones en tiempo real, ya que permite mostrar el estado en línea o fuera de línea de los usuarios. Este tutorial presenta una forma de implementar dicha funcionalidad en Bubble.
Esta solución ya no es viable para muchos casos de uso debido al uso intensivo que hace de las Workload Units de Bubble. Sin embargo, sirve como una demostración de las capacidades de Bubble y de una arquitectura apropiada.
Las soluciones alternativas implican la integración con servicios externos de websockets.
2. Concepto y arquitectura
El sistema de presencia funciona utilizando un mecanismo de “ping–pong”. El servidor inicia la comunicación enviando un ping a cada cliente, y cada cliente responde con un pong (heartbeat), indicando que está activo y conectado.
Este enfoque iniciado por el servidor garantiza un seguimiento de presencia en tiempo real, incluso en casos límite como interrupciones de conexión del cliente o hibernación del sistema operativo.
Estos escenarios impiden un monitoreo adecuado de la presencia, ya que los client-side workflows basados en eventos Do every X seconds no se recuperan correctamente tras dichas interrupciones sin un refresco de página. Por lo tanto, las soluciones más simples, basadas totalmente en lógica client-side. e.g. actualizar un timestamp cada X segundos, no son una opción viable.
3. Estructura de la base de datos
El sistema se basa en cuatro campos clave dentro del tipo de dato User:
- lastHeartbeatTimestamp – el pong, un timestamp que representa el último momento en que el usuario estuvo activo.
- status – indica si el usuario está online o offline.
- presenceWorkflowID – almacena el ID del API workflow que ejecuta el proceso de monitoreo (utilizado solo por el Super Admin).
- sendHeartbeat – el ping, un campo booleano que el sistema alterna para indicar cuándo los usuarios deben enviar una nueva respuesta en forma de heartbeat.
Estos campos permiten la sincronización entre los workflows del backend y la actividad del lado del cliente.
4. API workflow principal e interacción del cliente
El proceso de monitoreo comienza cuando el Super Admin agenda un API workflow, proporcionando un parámetro que define el ciclo de latido (heartbeat cycle) en segundos.
Este ciclo determina con qué frecuencia el sistema solicita los heartbeats, además de definir tolerancias y umbrales de tiempo.
El workflow llama a un custom event (Request Heartbeat from Users) que establece el flag sendHeartbeat para todos los usuarios.
En el lado del cliente, un client-side workflow detecta cuando este flag se activa y dispara el evento Active User Procedure.
Este evento actualiza el lastHeartbeatTimestamp del usuario, restablece el flag sendHeartbeat y establece el estado de presencia como online.
5. Recursive scheduling y verificación de la salud del proceso
Después de solicitar los heartbeats, el workflow se programa recursivamente para ejecutarse nuevamente un ciclo más tarde, garantizando un monitoreo continuo.
El sistema guarda el ID del workflow programado en el registro del usuario Super Admin, en el campo presenceWorkflowID.
Un workflow de verificación de salud (health-check) se ejecuta periódicamente para comprobar si el proceso principal sigue activo. Si el ID del workflow almacenado en el registro del Super Admin no ha cambiado después de dos ciclos, el sistema asume que el proceso principal se ha detenido y lo reinicia automáticamente.
Este mecanismo mantiene el sistema de presencia autosostenible y tolerante a fallos.
6. Detección de inactividad
Un API workflow independiente se encarga de monitorear la inactividad de los usuarios.
Busca a los usuarios cuyo lastHeartbeatTimestamp sea más antiguo que un umbral predefinido (basado en el ciclo de latido y los valores de tolerancia) y cuyo estado aún esté marcado como online.
Para estos usuarios, el workflow ejecuta el Inactive User Protocol, que actualiza su estado a offline.
Esto garantiza que los usuarios que se desconectan o permanecen inactivos se reflejen correctamente como offline después de un periodo específico de inactividad.
7. Resumen del flujo lógico
- El Super Admin inicia el API workflow de monitoreo con un ciclo de latido definido.
- El servidor activa el flag sendHeartbeat para todos los usuarios.
- Los clientes detectan el flag y envían un heartbeat (pong), marcándose como online.
- El API workflow principal se reprograma a sí mismo para mantener la operación continua.
- Un workflow de verificación de salud garantiza que el proceso siga activo.
- Un workflow de inactividad actualiza a los usuarios como offline si no se recibe un latido dentro del tiempo de tolerancia.
Proyectos relacionados
Recursos relacionados
Documentación adicional y recursos para ayudarte a implementar este tutorial