At Google, we use WebSockets extensively for real-time features like collaborative editing and live notifications. Here's what you need to know.
HTTP vs WebSocket
HTTP is request-response. WebSocket is full-duplex — both client and server can send messages independently after the initial handshake.
// Client-side WebSocket
const ws = new WebSocket("wss://api.example.com/ws");
ws.onopen = () => ws.send(JSON.stringify({ type: "subscribe", channel: "updates" }));
ws.onmessage = (event) => {
const data = JSON.parse(event.data);
handleUpdate(data);
};
ws.onclose = (event) => {
if (!event.wasClean) reconnectWithBackoff();
};The Handshake
WebSocket starts as an HTTP upgrade request. The server responds with 101 Switching Protocols. After that, the connection is persistent and bidirectional.
Production Gotchas
1. Reconnection Logic
Connections drop. Always implement exponential backoff:
function reconnectWithBackoff(attempt = 0) {
const delay = Math.min(1000 * Math.pow(2, attempt), 30000);
setTimeout(() => connect(attempt + 1), delay);
}2. Heartbeat/Ping-Pong
Load balancers and proxies kill idle connections. Send periodic pings to keep the connection alive. At Google, we use 30-second intervals.
3. Message Ordering
WebSocket guarantees order within a single connection, but if you reconnect, you might miss messages. Use sequence numbers or timestamps to detect gaps.
When NOT to Use WebSockets
- Server-Sent Events (SSE): If you only need server→client updates, SSE is simpler and works over HTTP/2
- Long Polling: For low-frequency updates where WebSocket overhead isn't justified
- HTTP/2 Server Push: For pushing resources, not data
Scaling WebSockets
Each WebSocket connection holds a TCP socket. At scale, you need sticky sessions or a pub/sub layer (Redis, Kafka) to broadcast across multiple server instances.