Web Sockets

[00:00:00]
>> Evgenii Ray: So, the WebSocket is the fastest way, how can we transfer the data between the server and the client? So, the WebSocket is the duplex push technologies, it means that the client can push the data and the server. And the way it works is that the client sends the handshake request through the HTTP/1 and the server sends the upgrade request, so response.

[00:00:27]
So, it basically tells, okay client, you can upgrade your protocol to TCP. So, because the WebSockets used the HTTP connection just to establish the initial connection and upgrade its TCP. And the communication that will be done after the upgrade header will be using the TCP instead of the HTTP.

[00:00:53]
So, the client can push the data and the server can respond, but what are the problems though with the WebSockets? The main issue with the WebSocket is that it's infrastructure wise, and engineering wise, it's very complex to maintain the WebSockets. It's very resource-consuming because the limit for the connection within their WebSocket can open 65,000 TCP socket connections with a server.

[00:01:32]
And if the TCP socket takes a lot of CPU resources to be maintained, and you would need to have a very good investment in your server infrastructure to support such load. And the amount of money that you need to put in the infrastructure will be incomparable to the server-side events because of the TCP sockets.

[00:01:56]
And it also drains energy and utilize CPU a lot, and it also used the duplex antenna, so it will really drain your battery pretty fast. The pros, though, for the WebSockets, if you need a real-time communication, this is the best way to go. And it's also, it has the unlimited number of connections, so if you're planning to have 500,000 connections in parallel, this is probably the way when you want to use the WebSockets.

[00:02:27]
But the use case is basically when you work with the machine sensors, and you're building some code that will gather the machine sensors' data and you need this data in real-time. Also, the online gaming is also a good way to utilize the WebSockets, trading, where the precise timing is important, especially micro-scoping, or when you need to have precise location tracking.

[00:02:52]
So, on average, I would recommend if you built the chat application, you don't really need the WebSockets. You can receive the message from the server-side events and POST the message using the normal POST request, and it will be much cheaper and easier infrastructure in the code wise. Also, the WebSockets are stateful, once you lose the connection with the WebSockets, you will lose all the data that was stored within the socket.

[00:03:18]
So, you need to maintain a separate infrastructure that will store the state in some database so you can restore it from the place you stop, that's why it's more complicated. And if you think that the WebSocket is good, think twice because it's a very big investment for the business in general.

[00:03:36]
And let's get back to our shop administration app, what we would use for the endpoints. So, to get the shopping dollars for desktop, we could consider a long polling because long polling for desktop sounds fine. And there's always the server-side events, while for mobile, we will use the server-side events to provide better performance, the same applies to getting new messages.

[00:04:03]
So, we can get the new messages using the server-side events, and for desktop, we could use the short polling, or again, the server-side events. For sending the message, for both cases, I would just use a normal HTTP POST request. You don't really need the WebSocket connection to POST the data to the server.

[00:04:23]
>> Speaker 1: Would SSE work for media files, like images and videos, as well?
>> Evgenii Ray: No, SSE is not good for the media content because the media content is by data. And you need to utilize the server-side events mostly for the text-based data, for the video content, I will utilize WebRTC instead.

[00:04:47]
>> Speaker 1: What is the best protocol for handling real-time editors like Notion?
>> Evgenii Ray: You mean like saving the state in Notion? Okay, so when you work with a Notion, you don't really need to have the WebSocket connection to save the data, so you can basically do the normal POST request to save the data.

[00:05:08]
>> Speaker 1: But what about real-time editing, like multiplayer?
>> Evgenii Ray: When it comes to real-time editing, you can utilize still, server-side events, but when it comes to collaborative editing, that is getting more complex because there are special data structures that store even the research papers, how to do the collaborative editing.

[00:05:32]
So, we can speak about about this for a few hours. So basically, a protocol wise, server-side event will be good, but you will need to optimize your data structures to support the collaborative editing.
>> Speaker 1: Someone said WebSockets.
>> Evgenii Ray: [LAUGH] So, it depends on, infrastructure wise, WebSockets are terrible, it's really hard to maintain them.

[00:05:59]
And you also need to implement lots of overhead, how you're handling the data on a WebSockets. So, you need to have the thoughtful decision when you want to use it, I would utilize the normal HTTP POST request to say the data, and the server-side events to receive the data.

[00:06:15]
If you try to compare the performance of server-side events, they are very close to the WebSockets, all WebSockets are really faster. I think for the basic cases, server-side event would handle that, even for Notion case, this would handle.