Stop 20 · Advanced TopicsTopics · 1/14

WebSockets

In short

Live cricket scores, chat apps and multiplayer games don't keep asking the server "anything new?". They keep one connection open and let the server push updates the moment they happen.

Applying persistent, bidirectional connections at an application level — powering live chat, collaborative editing, and real-time dashboards beyond the basic API.

The jaadu chats on a corded phone with a friend, with sound waves flowing both ways.

Think of it like this

A phone call, not SMS

Normal HTTP is like SMS: you send, wait for a reply, and the chat ends. A WebSocket is a phone call. Once connected, both sides can talk whenever they want, until someone hangs up.

Watch it happen

One connection, both sides talking

Browser

Chat server

GET / Upgrade: websocket

1/6The browser sends a normal HTTP request asking to switch protocols.

The big ideas

What you need to know

One long-lived connection

The browser opens a connection once and keeps it open, instead of a new request for every update.

Both sides can send

The server can push messages without waiting for the browser to ask. That's what makes it real-time.

Plan for drops

Mobile networks drop connections often. Reconnect automatically, with a growing delay between attempts.

Not always needed

If only the server sends updates, Server-Sent Events can be simpler. For rare updates, polling is fine.

See it in code

Walk through the code

1function connect() {2  const socket = new WebSocket("wss://chat.example.com");3 4  socket.onopen = () =>5    socket.send(JSON.stringify({ type: "join", room: "cse-a" }));6 7  socket.onmessage = (event) => showMessage(JSON.parse(event.data));8 9  // Network dropped? Try again after 2 seconds10  socket.onclose = () => setTimeout(connect, 2000);11}12 13connect();

1/4Open a secure WebSocket connection.

wss:// is the secure version, like https://. Real apps increase the retry delay after each failure so thousands of clients don't hammer the server at once.

Save yourself the pain

Common mistakes

Oops

Opening a new WebSocket inside a React component on every render.

Do this instead

Open it once, in an effect with a cleanup that closes it, or in a shared module the whole app uses.

Oops

Assuming every message arrives because the connection was open.

Do this instead

Messages can be lost during a drop. After reconnecting, fetch anything missed, for example using the last message ID.

Your mission

Build a two-tab chat

~40 min

Quick check

Your dashboard needs a new stock price every few seconds, and the browser never sends data back. Which option is often simpler than WebSockets?

Go deeper

1Build a small real-time feature (live chat or live counter) end-to-end.
2Handle reconnection logic when a WebSocket connection drops.
3Compare WebSockets to Server-Sent Events for one-way real-time updates.