Presence system development with Bubble

1. Overview of the Project

A presence monitoring system is an important feature of many real-time applications. It enables the display of the online/offline status of users. This tutorial presents a way of implementing such a feature in Bubble.

This solution is no longer viable for many use cases due to the intensive use it makes of Bubble Workload Units. However, it serves as a demonstration of Bubble capabilities and architectural approach.

Alternative solutions involve integration with third-party websocket services.

---

2. Concept and Architecture

The presence system operates using a “ping–pong” heartbeat mechanism. The server initiates communication by sending a ping to every client, and each client responds with a pong, signaling that it is active and connected.

This server-initiated approach ensures real-time presence tracking, even under edge cases of client connection outage and OS hibernation. These edge cases prevent a proper presence tracking due to Do every X seconds client-side workflows failing to recover after aforementioned halts. Therefore, simpler solutions, fully client-side, e.g. updating a timestamp every X seconds, are not an option.

---

3. Database Structure

The system relies on four key fields within the User data type:

1. lastHeartbeatTimestamp – the pong, a timestamp representing the last active moment of the user.
2. status – indicates whether the user is online or offline.
3. presenceWorkflowID – stores the ID of the backend API workflow running the monitoring process (used only by the Super Admin).
4. sendHeartbeat – the ping, a boolean field that the system toggles to signal when users should send a new heartbeat response.

These fields enable synchronization between backend workflows and client-side activity.

---

4. Main API Workflow and Client Interaction

The monitoring process starts when the Super Admin schedules an API workflow with a parameter defining the heartbeat cycle (in seconds).

This cycle dictates how often the system requests heartbeats, defines tolerances, and sets timing thresholds.

The workflow calls a custom event (Request Heartbeat from Users) that sets the sendHeartbeat flag for all users.

On the client side, a front-end workflow detects when the flag is raised and triggers the Active User Procedure event.

This event updates the user’s heartbeat timestamp, resets the flag, and sets the presence status to online.

---

5. Recursive Scheduling and Process Health Check

After requesting heartbeats, the workflow recursively schedules itself to run again one cycle later, ensuring continuous monitoring.

The system saves the scheduled workflow’s ID to the Super Admin’s User record, in the presenceWorkflowID field.

A health-check workflow runs periodically to verify if the main process is active. If the workflow ID stored in the Super Admin User record hasn’t changed after two cycles, the system assumes the main process has stopped and automatically restarts it.

This mechanism keeps the presence system self-sustaining and fault-tolerant.

---

6. Inactivity Detection

A separate API workflow monitors user inactivity.

It searches for users whose lastHeartbeatTimestamp is older than a predefined threshold (based on the heartbeat cycle and tolerance values) and whose status is still marked as online.

For these users, the workflow executes the Inactive User Protocol, which updates their status to offline.

This ensures that users who disconnect or become idle are accurately reflected as offline after a specific period of inactivity.

---

7. Summary of Logic Flow

1. Super Admin starts the monitoring API workflow with a defined heartbeat cycle.
2. The server raises the sendHeartbeat flag for all users.
3. Clients detect the flag and send a heartbeat (pong), marking themselves online.
4. The main workflow reschedules itself for continuous operation.
5. A health-check workflow ensures the process remains active.
6. An inactivity workflow updates users to offline if no heartbeat is received within tolerance.

---