Streaming events with Server-Sent Events and WebSockets

[00:00 - 00:10] Welcome, in this lesson, we will pick real technology, we'll let's just run the end of the backend through events. Let's begin by definition of a stream.

[00:11 - 00:17] What is a stream? A stream is data that is incredibly made available over time.

[00:18 - 00:27] And here, what's really important is the available. Because even in the standard request, very often, the response will be chunked.

[00:28 - 00:37] For instance, a TCP/EP request, the answer will be chunked. However, the answer will not be processed until every single chunk has been received.

[00:38 - 00:46] So, with that, I is incrementally sent, but not made available. Which streaming the partial data is already available can be processed.

[00:47 - 00:50] Let's see if we install the stream. This is where I exist of time.

[00:51 - 01:04] If you are a first event, hello, a second world, a third world, this is a message and so on. And as each chunk reads your client, we can process it and display it on the UI .

[01:05 - 01:11] Now, which protocol can let us stream the events over the network? There are two major protocols.

[01:12 - 01:18] The first is the server-cent event protocol. It's a non-well known, but very useful protocol.

[01:19 - 01:25] That lets us stream events from the server to the client. It's unidirectional.

[01:26 - 01:36] It's compatible with HTTP/2. It's deadless, meaning that, like a standard standpoint, you can add and remove the server as you want, as every server is interchangeable.

[01:37 - 01:43] And it's mainly main for text data. So, you will be expected to encode the data as text.

[01:44 - 01:57] Here is a simple diagram showing the global workflow of a protocol. At the beginning, you were making an HTTP request, it could be a get or a burst , you will see it later, to a server.

[01:58 - 02:12] And this is called, we ask for a text event stream. The server will respond with a either text/event stream and the request starts the server-cent event request.

[02:13 - 02:18] Now we can stream an event from the stream one by one. And we look in detail at now in the spec.

[02:19 - 02:26] This is the official HTML series at the spec. As you can see, it's made to enable the server to push data over HTTP.

[02:27 - 02:33] And let's take a quick peek at how it looks. This is an example of events.

[02:34 - 02:41] Each fly is an event. Data, some text data, and a message data with two lines.

[02:42 - 02:52] This is a message, an event, sorry. So, data gives the type of event and some text is the content.

[02:53 - 03:00] Often, we'll send a stringy file, geson. If you can see a geson, that will be stringy file.

[03:01 - 03:06] And then on the client's side, we will pass it. That makes it easy to transmit complete through the object.

[03:07 - 03:14] Now, this is a certain search event. It's quite easy to use, and it's enough for use case.

[03:15 - 03:22] But there is also another protocol, which is the WebSocket protocol. It's very powerful.

[03:23 - 03:29] It's more powerful than a Star Star Defense. WebSocket is a bi-directional connection between server and client.

[03:30 - 03:34] You can stream back and forth. It supports text and big pain point to be aware.

[03:35 - 03:41] It's stateful. That means that creates a connection between a given client and a given server.

[03:42 - 03:44] We'll see why this is a problem. Now, here is a diagram.

[03:45 - 03:52] We don't need to go over every detail. But the core idea is that the connection starts as a HTTP request.

[03:53 - 04:03] Then it gets switched to WebSocket, which is another protocol. And you have now a duplex connection, meaning bi-directional, between the client and the server.

[04:04 - 04:12] Once that is done, you can send any event you want from the client or server or to the server to a client. Why is this bi-directional connection a problem?

[04:13 - 04:21] Let's look at this diagram. As you can see, you have a client, you have a server, and now you've created a coupling between those two lessons.

[04:22 - 04:32] What is a problem? Because it's a very classic way of class scaling application is horizontal scaling, meaning when we are lacking resources, we just create a new instance of a server.

[04:33 - 04:36] But that we not work with WebSocket. Why?

[04:37 - 04:45] Because we need to maintain the connection between client and server one. And we cannot send the request of client one to server two.

[04:46 - 04:52] There are two solutions. And the solutions can be moderately difficult to implement using the circuit IO library.

[04:53 - 04:56] The first solution is sticky load balancing. What does it mean?

[04:57 - 05:08] We put a load balancer between the client and the server. And we make sure that any time a client makes a request, the request is all way rooted to the same server.

[05:09 - 05:22] That can be done on the API res or with a quick solution using an external queue, a pupsub, but it could be done for instance with the resistance. The idea is that the client sent a request.

[05:23 - 05:32] And let's imagine it sent to server two, but it was meant to go to server three . What does server two is put an event in the ready queue.

[05:33 - 05:37] And then server three is just kind. So we'll get notified and event was meant for it.

[05:38 - 05:50] And so in the end, the event correctly wants to server three. So of course, we said, if we want to scale our WebSocket architecture, we are forced to add a new component.

[05:51 - 05:55] And we are also forced now to address our server. How are we going to scale a red balancer?

[05:56 - 06:03] How are we going to scale our pups up? So from design systems and perspective, WebSocket is more complex.

[06:04 - 06:15] So to conclude, in this course, we will use a server sent event as it is simpler to implement the simple infrastructure and its fits our need. But both are correct.

[06:16 - 06:24] And if you want to, if you need WebSocket, go ahead is perfectly correct implementation. And that's the end of our introductory module.

[06:25 - 06:29] and now we'll begin building virtual app. See you soon!