Streaming events with Server-Sent Events and WebSockets

Project Source Code

Get the project source code below, and follow along with the lesson material.

Download Project Source Code

To set up the project on your local machine, please follow the directions provided in the README.md file. If you run into any issues with running the project source code, then feel free to reach out to the author in the course's Discord channel.

  • |

Lesson Transcript

  • [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!