Using WebSockets for a Live Calling Dashboard

# Using WebSockets for a Live Calling Dashboard A real-time calling workflow needs more than a good backend. It needs a way to show what is happening while the call is still in progress. Polling would work for a simple demo, but it becomes noisy and inefficient once you have multiple concurrent calls. For production, WebSockets are the better fit. ## The problem we wanted to solve During an active call, we wanted the UI to update for: - connection status - call duration - latest transcript snippets - agent or AI disposition updates - any failures or reconnect events Instead of asking the frontend to repeatedly fetch this state, we broadcast updates from the backend the moment something changes. ## How the flow works The backend receives events from the telephony bridge and from the AI layer. Each event is normalized into a simple message format and pushed to the frontend over a WebSocket channel. On the frontend, the client listens for updates and updates the Redux state locally. That means the dashboard can reflect live status changes without full page reloads or excessive requests. ## Why this is a good fit WebSockets make the experience feel immediate. They also reduce the complexity of building a dashboard around stale data. The frontend becomes a view over a live event stream rather than a set of snapshots. Some of the important benefits are: - lower latency for monitoring - cleaner UI state updates - less server load than repeated polling - a simpler mental model for real-time operations For a product like this, live visibility is part of the product itself.