<story><title>Server-sent events</title><url>https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events</url></story><parent_chain><item><author>no_wizard</author><text>I know alot of websites and engineers use Websocket for &lt;i&gt;push only&lt;/i&gt; data. SSE is tailored made for real time one sided updates!&lt;p&gt;In fact, I think it made a better chat protocol, when we built a chat system at a previous job, similar to Slack. We ended up leveraging SSE to push updates to channels and traditional HTTP requests to send data to the server, resulting in lower latency and less overhead on the server side. We did this because we found the following to be true:&lt;p&gt;- At any given time, there are far more people reading chat messages than writing them&lt;p&gt;- What matters is that updates after being sent to everyone else is that their pretty close to instantaneous but you had a 500ms window to allow for the server to receive a new message and then propagate it out. Therefore, for the sender, you update the UI optimistically so they aren&amp;#x27;t waiting for a response, and everyone else will get it in ~500ms and its imperceptible&lt;p&gt;- one downside: its harder (we never figured it out before I left) to do indicators for when someone is typing. That really does seem to require two way real time connections</text></item></parent_chain><comment><author>twic</author><text>The big problem i&amp;#x27;ve run into with SSE is the connection limit [1]:&lt;p&gt;&amp;gt; Warning: When not used over HTTP&amp;#x2F;2, SSE suffers from a limitation to the maximum number of open connections, which can be specially painful when opening various tabs as the limit is per browser and set to a very low number (6). The issue has been marked as &amp;quot;Won&amp;#x27;t fix&amp;quot; in Chrome and Firefox. This limit is per browser + domain, so that means that you can open 6 SSE connections across all of the tabs to www.example1.com and another 6 SSE connections to www.example2.com. (from Stackoverflow). When using HTTP&amp;#x2F;2, the maximum number of simultaneous HTTP streams is negotiated between the server and the client (defaults to 100).&lt;p&gt;The natural way to use SSE is to create an EventSource on each page. If you do this, and your user opens six tabs, they can now no longer make HTTP requests to your site. Not just SSE requests, any HTTP requests at all!&lt;p&gt;It&amp;#x27;s also quite natural, i think, to want to use multiple separate streams. It&amp;#x27;s very convenient to write separate endpoints for various kinds of data that a page might want, for example one for streaming numerical data, one for control messages, and one for descriptive events; or one for each panel on a dashboard. Here, you can hit the limit on a single page.&lt;p&gt;I wrote a thin layer over my HTTP server&amp;#x27;s APIs which lets me write a single handler which can send events via either SSE or a websocket. Then, when i build a page, i use websockets, but if i want to debug, i can still use curl to make a normal HTTP request. Also, other apps can use SSE to pull data, which only requires an HTTP client, not a websocket client.&lt;p&gt;[1] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;developer.mozilla.org&amp;#x2F;en-US&amp;#x2F;docs&amp;#x2F;Web&amp;#x2F;API&amp;#x2F;EventSource&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;developer.mozilla.org&amp;#x2F;en-US&amp;#x2F;docs&amp;#x2F;Web&amp;#x2F;API&amp;#x2F;EventSource&lt;/a&gt;</text></comment>
<story><title>Server-sent events</title><url>https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events</url></story><parent_chain><item><author>no_wizard</author><text>I know alot of websites and engineers use Websocket for &lt;i&gt;push only&lt;/i&gt; data. SSE is tailored made for real time one sided updates!&lt;p&gt;In fact, I think it made a better chat protocol, when we built a chat system at a previous job, similar to Slack. We ended up leveraging SSE to push updates to channels and traditional HTTP requests to send data to the server, resulting in lower latency and less overhead on the server side. We did this because we found the following to be true:&lt;p&gt;- At any given time, there are far more people reading chat messages than writing them&lt;p&gt;- What matters is that updates after being sent to everyone else is that their pretty close to instantaneous but you had a 500ms window to allow for the server to receive a new message and then propagate it out. Therefore, for the sender, you update the UI optimistically so they aren&amp;#x27;t waiting for a response, and everyone else will get it in ~500ms and its imperceptible&lt;p&gt;- one downside: its harder (we never figured it out before I left) to do indicators for when someone is typing. That really does seem to require two way real time connections</text></item></parent_chain><comment><author>franky47</author><text>One major issue I encountered with SSE is dealing with reconnection. WebSocket makes it very easy to detect differences between a loss of network connectivity, a server dying, and a client exiting properly (eg: closing the tab), on either side of the socket.&lt;p&gt;Maybe there are facilities to do so with SSE that I don&amp;#x27;t know of, but my experience in reliable server-to-client-only comms with it has been a bit rough.</text></comment>