InteractiveFrameworks

WebSockets

Make the cats API live: gateways on socket.io, acknowledgements and events, broadcasts, rooms and namespaces, the request pipeline (filters, pipes, guards and interceptors) around a message instead of a request, connections refused at the handshake, and tests that talk to a gateway like a client.

lessons
9
level
advanced
time
4.5 hours
Start with Your first gateway

Gateways

A connection that stays open: messages in, acknowledgements and events out, to one client, to everyone, or to a room.

  1. 1
    Your first gateway

    Open the cats API to socket.io clients: a gateway on the app's own port, message handlers that acknowledge with their return value, a property picked out of the payload, and an event sent back to the sender instead of an acknowledgement.

    Read the theory
  2. 2
    The server and its clients

    Make the desk feel live: lifecycle hooks for clients coming and going, the handshake's auth payload, the server behind the gateway, and the three ways to send an event: to one client, to everyone but the sender, to everyone.

    Read the theory
  3. 3
    Rooms and namespaces

    Send events to some clients only: a namespace that keeps the staff's channel apart from the public desk, rooms that clients join and leave, and the difference between telling a room and telling the rest of it.

    Read the theory
  4. 4
    Many answers, and the HTTP API

    Answer one message more than once: an Observable of events, a handler that waits for a promise, an acknowledgement sent by hand before the work is done, and a gateway the HTTP controllers use to tell every socket what changed.

    Read the theory

Around the handler

The request pipeline, around a message instead of a request: what errors look like on the wire, validation, who may send what, and code that runs around every handler.

  1. 5
    Exception filters

    Refuse a message the socket way: WsException with a message or an object, what every other error becomes on the wire, and a filter that sends the HTTP API's exceptions to a socket with their message instead of hiding them.

    Read the theory
  2. 6
    Pipes

    Validate what a socket sends: the ValidationPipe on a gateway, refusals turned into WsException so the client learns what was wrong, and a parameter pipe whose ordinary BadRequestException would reach the client only as Internal server error.

    Read the theory
  3. 7
    Guards and the handshake

    Decide who may do what, at two moments: a guard that reads the handshake and refuses one kind of message, and a socket.io middleware, installed by an IoAdapter of your own, that refuses the connection itself before any message is sent.

    Read the theory
  4. 8
    Interceptors and per-connection state

    Run code around every message, and keep state for each connection: an interceptor that audits who sent what through the WebSocket execution context, and a request-scoped provider that Nest 12 creates once per connection, with that connection's socket injected.

    Read the theory

Testing

Tests that talk to a gateway the way a client does.

  1. 9
    Testing a gateway

    Write the tests: end-to-end specs that start the application, connect socket.io clients to it, and check what every client receives, so that a broadcast reaching the wrong client, a refused adoption that goes through, or a departure nobody hears fails a test.

    Read the theory