Should I use Server-Sent Events or WebSockets for a one-way live transit map?
Asked by
MistyOrbit42
I'm a computer science student building a side project with a Node/Express backend and React frontend. The app will display a live transit map with tram arrival data pushed from the server to the browser. The client doesn't need to send real-time messages back; it may only make ordinary requests for things like filters or configuration. Most tutorials recommend Socket.io or WebSockets, but Server-Sent Events seem simpler because they use a standard HTTP connection. Is SSE the better choice for a one-way stream like this, and what important disadvantages should I consider? Why are WebSockets so often treated as the default?
Answers
Make sure the SSE endpoint sends heartbeats and that your server handles reconnects sensibly. Including event IDs lets the client send Last-Event-ID after a disconnect, so the server can resume or catch it up. Also check reverse-proxy buffering and idle timeouts, since those can prevent events from arriving immediately even when the application code is correct.
Reply to this answer
SSE is a very good fit here. It is designed for a persistent server-to-browser stream and works well for live dashboards, notifications, status pages, and transit updates. In the browser you can use EventSource, send JSON events, and let the client reconnect automatically. WebSockets are more appropriate when the client also needs to send frequent real-time messages, such as in chat, multiplayer games, or collaborative editing.
Reply to this answer
The main practical caveat is connection limits. With HTTP/1.1, browsers commonly allow only around six simultaneous connections per domain, and each open SSE stream uses one. That can become annoying if someone opens several tabs. HTTP/2 multiplexes streams and largely avoids this issue, so verify that production is actually serving HTTP/2. For one map stream, though, this probably won't be a problem.
Reply to this answer
WebSockets are often recommended because they support both directions and because tutorials tend to use them as a general-purpose real-time solution. They can also be more efficient for extremely frequent, tiny messages, but the difference usually isn't important for ordinary transit updates. If you later need the browser to send location changes, subscriptions, acknowledgments, or other low-latency data over the same connection, you can reconsider WebSockets. For the design you described, choosing SSE isn't cutting corners; it's matching the protocol to the communication pattern.
Reply to this answer
Add your answer
Answers are reviewed before publication.
Related Discussions