Skip to content

Instantly share code, notes, and snippets.

@krazylearner
Last active July 25, 2021 05:59
Show Gist options
  • Save krazylearner/a3614ba6efd366e930db to your computer and use it in GitHub Desktop.
Save krazylearner/a3614ba6efd366e930db to your computer and use it in GitHub Desktop.
WebSockets vs. Server-Sent events/EventSource
---------------------------------------------
Both WebSockets and Server-Sent Events are capable of pushing data to browsers. To me they seem to be competing technologies.
What is the difference between them? When would you choose one over the other?
Websockets and SSE (Server Sent Events) are both capable of pushing data to browsers, however they are not competing technologies.
Websockets connections can both send data to the browser and receive data from the browser.
A good example of an application that could use websockets is a chat application.
SSE connections can only push data to the browser. Online stock quotes, or twitters updating
timeline or feed are good examples of an application that could benefit from SSE.
In practice since everything that can be done with SSE can also be done with Websockets,
Websockets is getting a lot more attention and love, and many more browsers support Websockets than SSE.
However, it can be overkill for some types of application, and the backend could be easier to implement with a protocol such as SSE.
Server-Sent Events vs. WebSockets
###Why would you choose Server-Sent Events over WebSockets?
Good question.
One reason SSEs have been kept in the shadow is because later APIs like WebSockets
provide a richer protocol to perform bi-directional, full-duplex communication.
Having a two-way channel is more attractive for things like games, messaging apps, and for
cases where you need near real-time updates in both directions. However, in some scenarios
data doesn't need to be sent from the client. You simply need updates from some server action.
A few examples would be friends' status updates, stock tickers, news feeds,
or other automated data push mechanisms (e.g. updating a client-side Web SQL Database or IndexedDB object store).
If you'll need to send data to a server, XMLHttpRequest is always a friend.
SSEs are sent over traditional HTTP. That means they do not require
a special protocol or server implementation to get working. WebSockets on the other hand,
require full-duplex connections and new Web Socket servers to handle the protocol.
In addition, Server-Sent Events have a variety of features that WebSockets lack by design
such as automatic reconnection, event IDs, and the ability to send arbitrary events.
### summary:
####Advantages of SSE over Websockets:
Transported over simple HTTP instead of a custom protocol
Can be poly-filled with javascript to "backport" SSE to browsers that do not support it yet.
Built in support for re-connection and event-id
Simpler protocol
####Advantages of Websockets over SSE:
Real time, two directional communication.
Native suport in more browers
####Ideal use cases of SSE:
Stock ticker streaming
twitter feed updating
Notifications to browser
@gathm5
Copy link

gathm5 commented Aug 6, 2019

Awesome.. to the point!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment