What this prompt does
This prompt builds a scalable WebSocket server for [use_case] using [ws_library] with Node.js and TypeScript. It covers server setup integrated with [http_framework], connection authentication via [auth_method], room and channel management, a presence system with heartbeat, typed messages ([message_types]) as discriminated unions, horizontal scaling across [instance_count] nodes via [scaling_adapter], reconnection with message buffer and replay, binary support for [binary_use_case], per-connection rate limiting, monitoring, and a client-side TypeScript SDK with auto-reconnect.
The structure works because the gap between a WebSocket demo and a production system is exactly the hard parts this prompt names: scaling across nodes and reconnection-with-replay. A single-node socket server is trivial; broadcasting correctly across [instance_count] instances requires [scaling_adapter], and surviving a deploy requires buffering messages and replaying them on reconnect. By forcing those into the spec, the output addresses real failure modes instead of a happy-path demo.
When to use it
- When building real-time features like collaborative editing, chat, or live dashboards
- When connections must be authenticated via
[auth_method]before joining rooms - When you need presence (who is online) per room with heartbeat detection
- When scaling beyond one node and broadcasts must reach all
[instance_count]instances - When clients must survive a deploy or network blip without losing messages
- When you want a typed client SDK so frontend events match the server contract
- When a single misbehaving connection could flood a room and you need per-connection rate limiting
Example output
You get a TypeScript WebSocket server: setup wired to [http_framework], auth on the handshake validating [auth_method], room join/leave/broadcast logic, the presence and heartbeat system tracking online users per room, the [message_types] discriminated unions, the [scaling_adapter] configuration for multi-node broadcast across [instance_count] nodes, reconnection-with-replay handling, binary support for [binary_use_case], per-connection rate limiting, and a typed client SDK with auto-reconnect. It includes connection metrics — active connections, messages per second, errors, memory usage — rather than only the bare socket plumbing, so the result is closer to a deployable real-time backend for [use_case] than a single-file demo.
Pro tips
- Use the
[scaling_adapter](Redis adapter for Socket.IO) as soon as[instance_count]exceeds one; without it, a broadcast only reaches clients on the same node - Validate
[auth_method]on the handshake, not after connect, so unauthorized sockets never join a room - Test reconnection-with-replay against a real deploy; this path is what separates a demo from something that survives shipping
- Keep
[message_types]as discriminated unions so the client SDK and server agree on every event shape at compile time - Only enable binary support if
[binary_use_case]truly needs it; for text-only payloads it adds complexity for no gain - Set the per-connection rate limit deliberately so a single misbehaving client cannot flood a room
