I'm a computer science student building a live transit map with a Node/Express backend and a React frontend. The server needs to continuously send tram arrival updates to the browser, but the client doesn't need to send real-time messages back.
Many tutorials immediately recommend Socket.io or WebSockets, but Server-Sent Events (SSE) seems like a simpler HTTP-based option for a one-way stream. Is there an important drawback to SSE that I'm overlooking? Why are WebSockets so commonly recommended, and would SSE be the better choice for this particular application?
4 Answers
WebSockets would become useful if the client later needed to send frequent real-time information back—for example, its location, filters, subscriptions, or acknowledgements—so the server could send only nearby station updates. For the current one-way design, adding WebSockets would probably be unnecessary complexity.
SSE is a strong fit when the communication is only server-to-client. It works well for live dashboards, notifications, status pages, and transit updates, while WebSockets are more useful for genuinely two-way communication such as chat, multiplayer games, or interactive tracking. WebSockets are often recommended because they're flexible and widely used, not because they're automatically better for every real-time feature.
For SSE, use the browser's EventSource API, send structured events such as JSON, and include heartbeats so idle connections don't get closed unexpectedly. Supporting event IDs and Last-Event-ID can also help clients resume after reconnecting. In production, check that reverse proxies aren't buffering the stream and that their idle timeouts are configured appropriately.
WebSockets can have lower framing overhead after the connection is established, but that difference usually isn't important for normal transit updates. Both approaches avoid sending full HTTP headers for every individual message, and compression can reduce larger payloads. The more meaningful decision is the communication pattern: SSE is simpler for server-to-client events, while WebSockets provide a bidirectional channel.
The main browser limitation is connection count. With HTTP/1.1, browsers commonly allow around six simultaneous connections per domain, and an open SSE stream uses one of them. That can matter if someone opens several tabs or maintains multiple streams. HTTP/2 multiplexes streams and largely avoids this issue, so verify that production is actually using it.