WebSockets or server-sent events? Start with the direction of the conversation

A screen that updates without a reload is often called real-time, but that phrase does not pick a transport. The decision depends on how quickly a change must appear, whether the browser needs to send frequent messages, how many clients listen, and what recovery looks like after a disconnect.

Polling: a request when a delay is acceptable

With polling, a browser asks the server for updates every few seconds or minutes. It is easy to understand, works through ordinary HTTP infrastructure and recovers naturally on the next request. The cost is repeated traffic when nothing changes and the delay between a change and the next poll.

Polling is often enough for an administrative report or a status page where a short delay has no operational consequence. A conditional request or a cursor can avoid returning a full dataset each time. Do not replace a simple mechanism merely because a live transport sounds more advanced.

Server-sent events: one-way updates from server to browser

SSE keeps an HTTP response open so the server can send text events to the browser. It fits one-way updates such as a background export's progress, a notification feed or a long-running task. The browser's EventSource API reconnects after many interruptions, and the server can use event IDs to help the client continue from a known point.

The browser still sends commands through normal HTTP requests. That separation can make an application easier to reason about: commands use the usual authenticated API, while the stream reports state changes. Check proxy timeouts, buffering and connection limits in the deployment environment before relying on a long-lived response.

WebSockets: both sides exchange messages

A WebSocket begins as an HTTP upgrade and then keeps a bidirectional connection open. It is useful when the client and server both need to send frequent messages over one connection: collaborative editing, interactive control, or several restaurant stations coordinating orders and status changes.

The extra flexibility brings work. The server has to manage connections, authorise subscriptions, handle reconnects and protect against stale client state. A reverse proxy must preserve the upgrade. A client that reconnects should refresh its session and recover from a current server snapshot rather than assume it received every event.

What should reconnect do?

Treat a lost connection as a normal state. Show that the screen is stale, retry with a bounded delay, and authenticate again if necessary. After reconnecting, fetch an authoritative snapshot. If the application uses ordered events, include a sequence or cursor so the client can notice a gap and request missing changes or replace its local state.

For a restaurant kitchen display, the important question is not whether the transport is fashionable. It is whether a ticket can disappear while a device sleeps, whether a status change appears on the other screen, and whether reconnect restores a trustworthy view.

Does a real-time screen guarantee that every event arrived?

No. The connection can drop and a device can miss events. Design a recovery path using a fresh snapshot, a cursor or an explicit replay endpoint, and make the current connection state visible to staff.

Which transport should a small dashboard use?

Use polling if the acceptable delay is measured in minutes or seconds and traffic is modest. Use SSE when the server mainly streams updates to the browser. Use WebSockets when both sides need frequent, low-latency messages. Measure the actual workflow before adding operational complexity.