An Introduction to WebSockets
By and large, every developer is familiar with the HTTP protocol and that is because it is foundational to every website and application. When a user visits an URL or resource endpoint, they trigger a request to a server, asking for specific data only accessible at that endpoint. And so, once the server receives this request it sends back a response, which can be anything from a webpage to some data. This relationship where a client initiates communication via a request, and only then does the server engage in communication via a response is considered unidirectional. Again, communication is only initiated one way, via the client. This type of communication works fine when data is unchanging or at least, not changing frequently. If this is not the case, as in real-time data flows, then the HTTP protocol is not the best approach for communicating with the server and accessing data. Luckily, this is where the WebSocket protocol shines and offers a better solution.
The WebSocket protocol is another form of communication between the client and server, entirely separate from the HTTP protocol and differing in many ways. It works in what is known as a full-duplex or bidirectional communication meaning that communication is initiated not only via the client but also the server. Unlike the HTTP protocol, the server can reach out to the client and provide it data without the client needing to make a request. With HTTP requests, once the server sends its response to the client, the line of communication is closed, hence the client needing to make additional requests for data. With the WebSocket protocol, the initial connection made between the client and server, for example when a user visits an URL, is maintained open or persisted. And this persisted connection, known as a websocket connection, allows the server to initiate communication.
Connection persistence enables communication between multiple clients through the server. Just like in the HTTP protocol, where many clients can reach out to a server for data, with the WebSocket protocol clients can do the same. The key distinction is that the connections are kept open creating an environment where multiple clients are connected to each other through their open connections to the server. The open connections promote a constant flow of data between the server and client and between client and client. At the point of receiving an event (known as a response in the HTTP protocol) from the server, the client can then send a counter-response, or emit an event back to the server continuining the flow of data. Or in the case of client to client communication, an output from a client is relayed to other clients via the server. Another way to imagine this is with chat rooms, which serve as a connection point to the server, and each user who enters the room essentially is creating a websocket connection, or a persisted connection to the server. Once users join the room, they are all connected to each other, and when one user enters a message, the server receives that data and relays it to every other open connection, or user, creating that real-time data flow between clients.
There are three types of communications that can be carried with websocket connections. The first is the more traditional type between a server and client, the server emits an event to the connecting client, and the client listens for that event and can emit an event back to the server. Going back to the example of the chat room, when a new user joins a chat room, the serve can send the user a welcome message, and only the new user. The second type of communication is known as a broadcast, and differs in that the server can emit an event to all the other connected clients. When a new client connects to the server, establishing a websocket connection, every other previously connected client receives some communication from the server. The server can emit an event that is reserved for new connections, but also broadcast an event that is reservered for notifying other previously created and currently active connections. If a new user connects, the server emits a welcome even to that new user and also broadcasts to all other connected users that a new user has connected, or join the chat room. Lastly, the server can communicate with all connections, by emitting an event to each client regardless of when the connections were made. When a user inputs a message, that message is captured by the server and transmitted to all the open connections, resulting in each user being able to see the new message.
Understanding these differences and capabilities allow for rich real-time applications. The constant incoming of new information can be received by the server and emitted to all connected clients, without the clients having to guess on when to make requests to obtain the new data, or make multiple requests to keep up to date. There are many great articles on websockets, including implementation of them. Below you can check out the article which highlights the history communication via the internet.
