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
Gateways
A connection that stays open: messages in, acknowledgements and events out, to one client, to everyone, or to a room.
- 1Your 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 - 2The 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 - 3Rooms 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 - 4Many 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.
- 5Exception 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 - 6Pipes
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 - 7Guards 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 - 8Interceptors 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.
- 9Testing 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