Topic

WebSockets / Socket.IO

Definition

A WebSocket is a persistent, full-duplex connection between client and server that allows either side to push messages at any time, in contrast to HTTP request and response where the server can only reply to a request the client made.

In simpler words

WebSockets let the server tell the browser something happened right away, instead of the browser having to keep asking.

The judgment call: which features actually need a live push channel versus which just need a refetch or a short poll.

Open official example (opens in new tab)

After this you can

Explain the difference between polling and WebSockets
Name a tickets feature that justifies real-time push
Describe how auth works on a socket connection, since it is not automatic
Reason about horizontal scaling of stateful socket servers

When a live channel is worth the complexity

Definition

A feature benefits from WebSockets when the cost of a user not seeing an update immediately is high and the update frequency is unpredictable, unlike periodic polling which is acceptable when staleness of a few seconds is fine.

In simpler words

Use a live socket for moments that must show instantly. Use ordinary polling or refetch-on-focus for everything else.

Good candidates: a live typing indicator, a shared ticket board where teammates see status changes without refreshing, or a notification badge that must update the moment something happens.

Bad candidates: a settings page, a report only viewed occasionally, or anything where refreshing a cached query every thirty seconds or on window focus is indistinguishable to the user.

TanStack Query features such as refetch on window focus and stale time often solve keeping data fresh without any socket infrastructure at all. Reach for WebSockets only when push semantics change the experience meaningfully.

Client subscribes to one ticket

const socket = io('/tickets', { withCredentials: true });
socket.emit('subscribe', { ticketId });
socket.on('ticket.updated', (ticket) => {
  queryClient.setQueryData(['ticket', ticket.id], ticket);
});

A pushed event updates the same query cache a normal fetch would populate. Only the transport changes, not the ownership of state.

Auth and scaling are not automatic

Definition

A WebSocket handshake must carry the same authentication credential, such as an httpOnly cookie, that the HTTP API uses, and because a socket server holds open per-connection state, routing all of one client messages to the same server instance requires sticky sessions or a shared pub-sub backbone across instances.

In simpler words

A socket connection needs to prove who the user is just like an HTTP request does, and running more than one server instance requires a way to share who is connected where.

Do not assume a socket connection is authenticated just because the earlier HTTP login succeeded. The handshake must present the same cookie or token, and the guard equivalent runs on connect.

A single Nest instance can hold all active sockets in memory. Two or more instances behind a load balancer need either sticky sessions, so the same client always reaches the same instance, or a shared broadcaster, such as Redis pub-sub, so an event published on one instance reaches a socket connected to another.

This is the same lesson as caching and queues: a stateful in-memory feature that works on one instance can silently break the moment it scales horizontally.

Keep in mind

Prefer query refetch or polling until a feature genuinely needs sub-second push.
Authenticate the socket handshake explicitly; never assume it inherits HTTP auth for free.
Plan for more than one server instance before relying on in-memory socket state.

Test

Check your understanding

At least 10 questions — mix of concept, syntax, practical, and logic. Score ≥80% (enforced by the API) to save progress.

Checking your session…

15 questions · concept 5 · syntax 3 · practical 4 · logic 3

1. When are WebSockets appropriate?

Concept

When many clients need server push updates in realtimeWhen a request needs a guaranteed synchronous response bodyWhen you need cacheable, bookmarkable GET endpointsWhen uploading large files that need resumable transfers

2. Should sockets skip auth?

Syntax

Yes — the CORS/Origin check on the handshake is sufficientNo — authenticate connections like protecting HTTPYes — sockets ride on an already-authenticated HTTP pageYes — validate identity only when a write message arrives

3. Who owns ticket write rules over sockets?

Practical

Nest still owns authorization and persistenceThe gateway class owns them, bypassing the service layerThe Socket.IO room configuration enforces themThe connecting client enforces them before emitting

4. Why keep REST alongside sockets?

Logic

REST is needed only for the initial socket handshakeSockets cannot return a response to a specific callerREST is required to authenticate every socket messageCRUD/query contracts stay simple; sockets push events

5. What should a socket gateway verify?

Concept

The same identity/roles you would trust on HTTPThat the handshake carried a matching CSRF tokenThat the client’s Origin header is on the allowlist onlyThat the transport upgraded to WebSocket, not polling

6. Are sockets ideal for file uploads of large blobs?

Practical

Yes — binary frames stream more efficiently than HTTPYes — the persistent connection avoids re-auth per chunkYes — Socket.IO chunks large payloads automaticallyUsually no — prefer dedicated upload HTTP flows

7. What event should clients get after a ticket update?

Syntax

A pushed domain event after Nest persists successfullyAn optimistic event emitted before the DB write commitsThe full DTO the client sent, echoed straight backA broadcast to every connected client regardless of room

8. Can unauthenticated sockets subscribe to private tickets?

Logic

Yes — as long as they never emit write messagesYes — room names are unguessable enough to protect themYes — the gateway filters events after they are sentNo — authorize channel membership

9. Why not prefer WebSockets for every CRUD?

Concept

WebSockets cannot carry authentication tokensRequest/response HTTP remains clearer for many operations and toolingWebSockets bypass Nest guards and pipes entirelyWebSockets require a new connection per message

10. Which claim is true?

Practical

Realtime is complementary to REST; Nest still owns authz and persistenceSockets remove the need for guards once connectedA gateway can persist tickets without the service layerRooms authorize themselves once a client joins

11. What is the security gap here?

Conceptadvanced

@WebSocketGateway()
export class TicketsGateway {
  @SubscribeMessage('delete')
  onDelete(@MessageBody() id: string) {
    return this.svc.remove(id);
  }
}

The handler returns a value instead of emitting an eventThe id is a string instead of a validated DTOThe gateway lacks a namespace, exposing the default oneThe socket message deletes without authenticating or authorizing the connection

12. Why emit after the service update?

Syntaxintermediate

await this.svc.update(id, dto);
this.server.emit('ticket.updated', updated);

Emitting first lets the client roll back on a failed saveThe server can only emit inside an async handler’s endEmitting before the update skips the guard checkClients should be notified only after the change is durably persisted

13. What is the right division of labor here?

Practicalintermediate

// REST: GET /tickets
// WS: emit ticket.updated

REST authenticates while sockets handle all writesSockets poll the REST endpoints on an intervalREST is only a fallback when the socket disconnectsREST handles CRUD and queries; sockets push realtime events

14. What must you check before letting a client join this room?

Logicadvanced

client.join('ticket:' + ticketId);

That the room name is under the maximum lengthThat the client is not already in another roomThat the ticket id exists before creating the roomThat the authenticated user is allowed to view that ticket

15. Why is this usually the wrong transport?

Conceptintermediate

@SubscribeMessage('upload')
onUpload(@MessageBody() bigFile: Buffer) {}

Large blob uploads are better handled by dedicated HTTP upload flowsBuffers cannot be serialized over a WebSocket frameThe gateway cannot apply a size limit to the payloadSocket.IO drops any message larger than 64KB

Checking your session…