WebSocket: two-way connection for real-time messages

Useful to know

With a simple update, the page can periodically ask the server if there is anything new. WebSocket offers another model: a two-way communication session opens and both parties can exchange messages through it. MDN indicates as the main option the receipt of data without a constant request for an answer. [1] This is a useful starting point for a chat, a table of current events or other interface where new information must reach the client in a timely manner.

It is important that the connection differs from the form of the message itself. The application decides what the data sent means and how the recipient should process it. The WebSocket object provides an interface for creating and managing the connection, sending and receiving. [2] It does not define itself what a "new order" or "read message" is. These meanings are a contract between the client and server code, which must remain consistent with changes in both parts of the system.

There are properties for the current state of the connection and for the amount of data waiting to be sent. Sending and closing methods are also separate actions. [2] Thus, the interface can distinguish preparation, working connection, and disconnection. For the user, this is important: a pressed button should not automatically present itself as a confirmed record if the message has not yet been processed across the street. The technical sending and confirmation of the meaning operation are two different steps from a single stream.

The classic WebSocket interface has no automatic reverse pressure mechanism. If incoming messages arrive faster than the application processes them, data and load can accumulate. [1] Therefore, an open connection does not negate the need for constraints and thoughtful processing. More frequent sending is not an end in itself. For each scoreboard, it is necessary to consider which changes are significant and whether it makes sense to show all intermediate values separately to the person in front of the screen.

Let's take an example with a general list of tasks. One participant changes a record and the others have to see the new state. In addition to the notification itself, answers to questions about missed messages, disconnection and reconnection are needed. If the browser was closed, the system should know where to get the current picture. This is an example of applied logic. WebSocket provides a channel for communication, but does not automatically create history, access permissions, and rules for enabling concurrent changes.

Upon inspection, successful connection, sending, receiving and disconnection are observed. It then experiences reconnection and behavior in a larger stream of messages. This can distinguish a channel problem and a data meaning problem. A well-designed interface shows fairly whether the information is current or if the connection is broken. It is this clear relationship between communication and user status that makes technology a useful part of the application, instead of just a technical check mark for "real time".