Real-Time Data and Live Updates

Real-time dashboards update as data changes. Live activity feeds, operational dashboards, trading dashboards. But real-time isn't always necessary, and it adds significant complexity. Understand when you actually need it.

When Real-Time Actually Matters

Operational monitoring: system health, active requests, error rates. Operators need to know immediately when something breaks.

Live activity: chat messages, social media feeds, collaborative editing. Users expect near-instant visibility.

Trading and bidding: auctions, financial trading, stock monitoring. A few second latency loses money.

Not needed: monthly revenue, quarterly metrics, strategic KPIs. Hourly or daily updates are fine.

Polling: The Simple Approach

Client makes requests every N seconds: "has anything changed?" Simplest to implement. Browser JavaScript with setInterval.

Downsides: wastes API calls when nothing changed, latency proportional to polling interval, creates unnecessary traffic.

Good for: non-critical updates, low-frequency changes, simple implementations.

WebSockets: Persistent Bidirectional Connection

Client and server establish a persistent connection. Server pushes updates to all connected clients. Changes appear immediately on all dashboards.

Advantages: instant updates, no wasted requests, efficient. Disadvantages: server complexity, sticky sessions if scaled horizontally, persistent connections require infrastructure.

Server-Sent Events (SSE)

One-way push from server to client over HTTP. Server sends events, client receives them. Simpler than WebSockets when you only need server-to-client updates.

Advantages: works over HTTP, no special protocol. Disadvantages: unidirectional, client can't send messages efficiently.

Supabase Realtime

Supabase built on WebSockets. You subscribe to database changes. Whenever a row is inserted/updated/deleted, the subscription receives an event.

Example: subscribe to the orders table. When a new order is created, your dashboard gets a notification and updates immediately.

This is powerful for dashboards. No custom WebSocket infrastructure needed. Supabase handles the connections and broadcasts.

Push Complexity Costs

Real-time requires infrastructure. Multiple server instances need to share a message queue (Redis, RabbitMQ). When server A receives an update, it must broadcast to clients connected to servers B, C, and D.

Sticky sessions: a user's WebSocket connects to server A. If A dies, the connection is lost. Requires load balancer awareness or session affinity.

These are manageable but add complexity. For small teams, managed services like Supabase eliminate this.

Stale-While-Revalidate Pattern

Show cached data immediately while fetching fresh data in the background. User sees something immediately (good UX) and data is updated automatically (eventual freshness).

Excellent for dashboards where a few seconds of staleness is acceptable but immediate display is important.

Deciding on Refresh Frequency

Real-time: for operational monitoring and live activity.

30-second refreshes: for frequently-changing metrics (page views, active users).

Hourly refreshes: for slowly-changing metrics (daily totals, trends).

Daily refreshes: for strategic metrics (revenue, profitability, growth).

Match update frequency to how often decisions are made. If you check a metric once a day, daily updates are fine.

Fallbacks and Degradation

If WebSocket connection fails, fall back to polling or show stale data. Users should see something, not a broken dashboard.