My understanding is that HTTP streaming involves the client sending an HTTP request and then response to the request being sent over time allowing the server to essentially push to the client. In what I have read it seems that SSEs operates along the same principle but, is more formalized. Is that close to a correct understanding?
I saw these questions but they didn't really answer my question directly.
HTTP: what are the relations between pipelining, keep-alive and Server Sent Events? What are Long-Polling, Websockets, Server-Sent Events (SSE) and Comet?
I also looked at this https://www.html5rocks.com/en/tutorials/eventsource/basics/#disqus_thread tutorial for setting up SSEs and it seems like how I would imagine HTTP streaming is set up.
Since SSE is based on the HTTP protocol, scaling can be achieved with means such as load-balancing. However, you'd need to ensure some sort of shared resource behind the servers so they're all kept in sync with new event updates.
A server-sent event is when a web page automatically gets updates from a server. This was also possible before, but the web page would have to ask if any updates were available. With server-sent events, the updates come automatically.
HTTP Streaming is a push-style data transfer technique that allows a web server to continuously send data to a client over a single HTTP connection that remains open indefinitely.
They are commonly used to send message updates or continuous data streams to a browser client and designed to enhance native, cross-browser streaming through a JavaScript API called EventSource, through which a client requests a particular URL in order to receive an event stream.
SSE is in fact a form of HTTP streaming. It is just an HTTP response with MIME type of "text/event-stream" and it sends plain text messages terminated with double newlines.
SSE is not something that was impossible to do before, but the website had to use WebSocket connection, AJAX long polling, comet, periodical polling etc. and now with SSE the API is standardized and the implementation is very simple. See:
https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events
One of the things to keep in mind is that SSE is not supported on IE including Edge and IE Mobile:
So you cannot really use it for wider audience (yet), unless you know what browser they use.
IMHO, HTTP2 Server sent events has rich features than HTTP Streaming.
In a unidirectional data flow (Server -> Client) where client side could be orchestrated based on backend events, server sent events could be a good choice.
For example:
# ---------- client side -----------
const eventSource = new EventSource("//your-api/workflow/state");
eventSource.addEventListener("queued", function(event) {
...
}
eventSource.addEventListener("started", function(event) {
...
}
eventSource.addEventListener("failed", function(event) {
...
}
eventSource.addEventListener("success", function(event) {
...
}
Limitations of Server sent events:
HTTP Streaming
There are many use cases where HTTP streaming could be useful. If we are only interested in a stream of message from Server, this could be handy.
Example scenario :
Let's say we like to stream a log file content to client. Either it could be a huge file or the file content keeps updating and we like to send it to client (like a log tail). In such case, HTTP stream (Transfer-Encoding: chunked
) could satisfy our needs.
# ---------- client side -----------
const streamRequest = (url) => {
fetch(url).then(function (response) {
let reader = response.body.getReader();
let decoder = new TextDecoder();
return readData();
function readData() {
return reader.read().then(function ({value, done}) {
console.log(value)
if (value) {
let newData = decoder.decode(value, {stream: !done});
console.log(newData);
}
if (done) {
console.log('end of stream');
return;
}
return readData();
});
}
});
}
Limitations of Stream response:
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With