What are WebSockets?

A WebSocket is a persistent, two-way connection between client and server, letting either side push messages the instant they happen. HTTP made the web by asking; WebSockets made it live by listening — one standardized upgrade (RFC 6455) turns a request into an open channel, and everything real-time on the web — chat, presence, tickers, collaborative cursors — rides on it.

Key takeaways

How the WebSocket Handshake Upgrade Works (HTTP 101)

GET /chat HTTP/1.1                      ← starts as ordinary HTTP
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==

HTTP/1.1 101 Switching Protocols        ← and stops being HTTP here
Upgrade: websocket
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

# From now on: tiny frames (2–14 bytes overhead), both directions,
# vs ~500+ bytes of headers for every single HTTP poll.

Most applications shouldn’t hand-roll what comes next — the production idiom is a managed real-time layer where the socket, heartbeats, and reconnection are somebody else’s code:

// JavaScript / Node.js — Back4app JS SDK (Live Query over WebSockets)
// One WebSocket, managed for you: connect, subscribe, reconnect
const query = new Parse.Query('Message');
query.equalTo('room', 'general');

const subscription = await query.subscribe();  // wss:// under the hood
subscription.on('create', (msg) => appendToChat(msg));
subscription.on('open', () => setStatus('live'));
// Later: subscription.unsubscribe();

// Flutter / Dart — Back4app Flutter SDK (Live Query over WebSockets)
// One WebSocket, managed for you: connect, subscribe, reconnect
final liveQuery = LiveQuery();
final query = QueryBuilder<ParseObject>(ParseObject('Message'))
  ..whereEqualTo('room', 'general');

final sub = await liveQuery.client.subscribe(query); // wss:// under the hood
sub.on(LiveQueryEvent.create, (msg) => appendToChat(msg));

// iOS / Swift — Back4app Swift SDK (Live Query over WebSockets)
// One WebSocket, managed for you: connect, subscribe, reconnect
let query = Message.query("room" == "general")

let subscription = query.subscribeCallback   // wss:// under the hood
subscription?.handleEvent { _, event in
  if case .created(let msg) = event { appendToChat(msg) }
}

// Android / Kotlin — Back4app Android SDK (Live Query over WebSockets)
// One WebSocket, managed for you: connect, subscribe, reconnect
val client = ParseLiveQueryClient.Factory.getClient()
val query = ParseQuery.getQuery<ParseObject>("Message")
query.whereEqualTo("room", "general")

val handling = client.subscribe(query)       // wss:// under the hood
handling.handleEvent(SubscriptionHandling.Event.CREATE) { _, msg ->
  appendToChat(msg)
}

WebSockets vs. everything else that moves data

Running sockets in production

Four concepts carry the operational load. Session affinity: connections are stateful, so load balancers must keep each client pinned to its server node. Fan-out: broadcasting one message to ten thousand subscribers across many nodes requires a pub/sub backplane between servers — the message travels server-to-server before it travels server-to-client. Backpressure: a slow phone on a bad network can’t be allowed to buffer unbounded messages in your server’s memory; drop, coalesce, or disconnect. Liveness: ping/pong frames plus application heartbeats detect half-dead connections, and clients reconnect with exponential backoff and jitter, then resubscribe their state — the step naive implementations forget. None of this is exotic; all of it is why “we’ll just open a socket” becomes a platform decision.

From messages to sync: the layer above

Raw WebSockets move bytes; applications want state. The step up is real-time sync: instead of hand-rolling message types and client-side bookkeeping, you subscribe to data — a query, a document, a channel — and the layer delivers precise change events, handles reconnect-and-catch-up, and applies server-side permissions per subscriber. That’s the live queries model: WebSockets as the transport, a query engine as the brain. If your WebSocket code is accumulating switch statements over message types, you are rebuilding this layer by hand.

Common use cases

• Chat and messaging — the canonical case: both sides talk, instantly.
• Presence — who’s online, who’s typing: tiny messages, high frequency, both directions.
• Collaborative editing — shared documents and whiteboards, where cursor positions and edits stream continuously.
• Live dashboards and tickers — server-push of changing numbers; SSE also fits when one-way.
• Multiplayer and location — game state and moving map markers, where latency is the product.

Do you need a socket? A decision matrix

And the middle path the matrix hides: server-to-client-only cases (feeds, notifications) fit SSE with less machinery — the full transport comparison has its own entry in this glossary’s registry.

Limitations and trade-offs

• Statefulness is the price of push. Every open connection is server memory and a load-balancing constraint; HTTP’s statelessness was carrying more weight than it seemed.
• Networks hate long-lived connections. Proxies, mobile radios, and laptops closing lids all sever sockets constantly — reconnection logic isn’t an edge case, it’s the main loop.
• Security moves to the connection. Authenticate at connect time, validate every message, enforce authorization per subscription — and always wss.
• Caching doesn’t exist here. Everything pushed is computed and delivered per client; the CDN can’t help you.
• Hand-rolled sync is a trap. The gap between “opened a socket” and “correct, reconnecting, permissioned state sync” is where the real engineering lives — which is precisely the layer worth renting.

WebSockets on Back4app

Back4app is an open-source Backend-as-a-Service (BaaS) platform that combines a managed database, auto-generated REST and GraphQL APIs, authentication, file storage, and Cloud Code serverless functions. Its real-time layer is Live Query: the WebSocket transport, heartbeats, reconnection, and multi-node fan-out run as managed infrastructure (the open LiveQuery protocol underneath), while your code subscribes to queries and receives typed change events — with ACLs enforced per subscriber, so real-time never bypasses the permission model. The code tabs above are the entire client-side story.