What Are WebSockets? Real-Time Features Explained

Most of the web works like a conversation where only one side can start talking: the browser asks, the server answers. That's fine for loading pages. It's a problem when the server has something new to say — a new chat message, a notification, a price change — and the browser hasn't asked.

Real-time features solve that. Here's how, from simplest to most capable.

The problem

Normal HTTP requests are request → response → done. (What Is an API?.) After the response, the connection is finished. The server can't reach out to the browser on its own.

So how does a chat app show a new message the instant it's sent?

Option 1: polling

The browser simply asks again and again: "anything new?" every few seconds.

setInterval(async () => {
  const res = await fetch("/api/messages?since=" + lastId)
  const newMessages = await res.json()
  // add them to the page
}, 5000)

Pros: trivial, works everywhere, no special server setup. Cons: up to five seconds of delay; lots of wasted requests when nothing's changed; more load as users grow.

Polling is honestly fine for many features — a dashboard refreshing every 30 seconds, checking whether an export has finished. Don't dismiss it.

Option 2: server-sent events (SSE)

The browser opens a connection that stays open, and the server sends messages down it whenever it wants. One direction only: server → browser.

const events = new EventSource("/api/notifications")
events.onmessage = (event) => {
  console.log("New:", event.data)
}

Pros: simple, built into browsers, reconnects automatically, works over normal HTTP. Cons: one-way — the browser still uses normal requests to send things.

SSE is how many AI chat apps stream responses word by word. It's a great fit for notifications, live feeds, and progress updates.

Option 3: WebSockets

A WebSocket is a connection that stays open and lets both sides send messages at any time. It starts as a normal HTTP request, then "upgrades" into a two-way channel.

const socket = new WebSocket("wss://chat.example.com/room/42")

socket.onmessage = (event) => {
  showMessage(JSON.parse(event.data))
}

socket.send(JSON.stringify({ text: "Hello!" }))

(wss:// is the secure version, like https://.)

Pros: truly two-way, low latency, efficient for frequent messages. Cons: more to manage — reconnecting after dropped connections, scaling across servers, authentication — and your hosting must support long-lived connections.

WebSockets suit chat, multiplayer games, collaborative editing, and live cursors.

Which one?

Need	Use
Updates every 10+ seconds are fine	Polling
Server pushes updates; browser rarely sends	Server-sent events
Streaming AI responses	Server-sent events (or streaming fetch)
Rapid two-way messages: chat, games, collaboration	WebSockets

Hosted real-time services

You don't have to run it yourself. Several services handle the connections for you:

Supabase Realtime and Firebase — subscribe to database changes directly. (Supabase vs Firebase.)
Pusher, Ably, and similar — send a message from your server; they deliver it to connected browsers.
Libraries like Socket.IO add reconnection, rooms, and fallbacks on top of WebSockets if you do run it yourself.

For a first real-time feature, a hosted service or your database platform's real-time feature is usually the fastest path.

What real-time needs from hosting

If you run SSE or WebSockets yourself:

Long-lived connections. Many serverless platforms end requests after a timeout, which breaks persistent connections. An always-on server handles them naturally. (What Is Serverless?.)
Proxy support. Anything in front of your app — a reverse proxy, load balancer, or CDN — must allow WebSocket upgrades and not buffer SSE streams. (Reverse Proxies Explained.)
Sharing messages across instances. If you run two copies of your server, a message arriving at one must reach users connected to the other. Usually done with Redis pub/sub. (Redis: When You Actually Need It.)
Authentication. Check who's connecting, and what they're allowed to subscribe to — a user shouldn't be able to join someone else's chat room by changing an ID. (Authentication vs Authorization.)
Reconnection. Connections drop — phones switch networks, laptops sleep. Clients must reconnect and catch up on missed messages.

EasySpawn runs your app as an always-on server, so long-lived WebSocket and SSE connections just work — with Redis available on the Team plan for sharing messages across processes. See how it works or join the waitlist.