WebSocket

One connection held open so server and client can both send messages any time, with no new request per message.

keep the line openreal-time back-and-forthweb socketwebsocketssocket connectionthe socket.io kind of thinglive two-way connectionpush updates both ways without refreshing

See it

Live demo coming soon

What it is

A WebSocket starts life as a normal HTTP request that asks to be upgraded, then stops being HTTP entirely: one TCP connection stays open and both sides send messages whenever they feel like it. No new request per message, no headers per message, none of the per-request HTTP overhead, which is what makes low-latency delivery possible. How low is up to physics and traffic: distance, congestion, server load, and any proxy in the path all still get a vote. The URL scheme gives it away: 'ws://' in development, 'wss://' anywhere real.

Reach for it when both directions matter and latency is the point: chat, multiplayer, collaborative cursors in Figma-style editors, live trading screens, presence indicators. Most teams use a library (Socket.IO, Phoenix Channels, Ably, Pusher) rather than the raw API, because the library ships the parts everyone eventually needs: rooms, reconnection with backoff, and fallbacks.

Gotcha: the connection will drop, on every phone, every day, and reconnecting is the easy half. The hard half is resyncing state that changed while you were gone, so send a sequence number or snapshot on reconnect. Also send heartbeats (ping frames) because idle proxies kill quiet connections after a minute or so, and remember that scaling past one server needs sticky sessions or a shared pub-sub backplane. If the client never talks back, SSE is the cheaper answer.

Ask AI for it

Build this feature on a WebSocket connection over 'wss://'. Define a small JSON message protocol with a 'type' field per message, authenticate on connect with a short-lived token, and join the client to a room or channel so broadcasts only reach the right people. On the client, wrap the socket in a manager that reconnects with exponential backoff and jitter, queues outbound messages while offline, requests a state snapshot after reconnect, and exposes connection status to the UI. Add ping/pong heartbeats every 30 seconds to keep proxies from closing an idle connection.

You might have meant

server sent eventslong pollingpollingevent bus pub subtimeout

Go deeper