What is realtime full-stack?
Realtime features push updates from the server to the client as they happen — chat messages, live notifications, collaborative edits, presence — instead of the client polling. WebSockets (or server-sent events) hold an open channel, and the UI updates the moment data changes.
Why it matters
Many modern features feel broken without realtime: a chat that needs a refresh, a dashboard that lags. Building it end to end touches a persistent server connection, client state updates, and scaling concerns. It is a high-value capability and a genuine step up in full-stack complexity.
What to learn
- WebSockets versus server-sent events versus polling
- Holding a connection on the server
- Pushing updates and updating client state
- Reconnection and dropped connections
- Authenticating a realtime connection
- Scaling across server instances with pub/sub
- Optimistic UI with realtime confirmation
Common pitfall
Building realtime on a single server and assuming it scales. WebSocket connections are stateful and pinned to one process, so with multiple instances a message published on one is invisible to clients on another. You need a shared pub/sub layer (often Redis) to broadcast across instances — design for that before you scale out.
Resources
Primary (free):
- MDN — WebSockets API · docs
- MDN — Server-sent events · docs
- Ably — Realtime concepts · article
Practice
Build a live feature: a WebSocket (or SSE) channel that pushes an update to all connected clients when data changes, updating the UI without a refresh. Handle reconnection. Then describe what breaks with two server instances and how pub/sub fixes it. Done when two browser tabs update together.
Outcomes
- Choose between WebSockets, SSE, and polling.
- Push server updates and reflect them in the UI.
- Handle reconnection and authenticate the connection.
- Scale realtime across instances with pub/sub.