📱 WebSockets

WebSocket = Protocol for persistent, bidirectional communication

Regular HTTP:
  Client: "Any updates?"
  Server: "No"
  Client: "Any updates?"
  Server: "No"
  Client: "Any updates?"
  Server: "Yes, here!"

WebSocket:
  Client: "Keep this line open"
  Server: "OK"
  ... (line stays open) ...
  Server: "Here's an update!" (instant)
  Client: "Got it!"

1. Client sends HTTP request:
   "I'd like to upgrade to WebSocket"

   GET /chat
   Upgrade: websocket
   Connection: Upgrade

2. Server agrees:
   "OK, upgraded!"

   101 Switching Protocols
   Upgrade: websocket

3. Connection upgraded
   Now speaking WebSocket protocol

Bidirectional messaging:

Client ─────────────────────────→ Server
        "Hello!"

Client ←───────────────────────── Server
        "Hi back!"

Client ←───────────────────────── Server
        "New message arrived!"
        (Server pushes, client didn't ask)

User sends message → Appears quickly for connected users
No constant polling.
No page refresh.

New email? Push notification immediately.
Stock price changed? Update the chart.
Friend came online? Show indicator.

Google Docs, Figma.
One person types → Others can see it.
Real-time cursor positions.

Multiplayer games.
Player moves → Others see it quickly.
Low latency critical.

Stock tickers.
Sports scores.
Social media feeds.

┌─────────────────────────────────────────────────────┐
│                     Clients                          │
│   ┌────────┐    ┌────────┐    ┌────────┐            │
│   │Client 1│    │Client 2│    │Client 3│            │
│   └───┬────┘    └───┬────┘    └───┬────┘            │
└───────┼─────────────┼─────────────┼─────────────────┘
        │             │             │
        │ WebSocket   │ WebSocket   │ WebSocket
        │ Connection  │ Connection  │ Connection
        │             │             │
┌───────▼─────────────▼─────────────▼─────────────────┐
│                  WebSocket Server                    │
│                                                      │
│   Maintains all connections                          │
│   Broadcasts to all or specific clients             │
└──────────────────────────────────────────────────────┘

Most common.
JSON payloads.

{ "type": "chat", "message": "Hello!" }

For audio, video, files.
Efficient for large data.

Ping/Pong: Keep connection alive
Close: Graceful shutdown

Users subscribe to rooms.
Messages typically go to room members.

Chat room: #general
  → Alice
  → Bob
  → Charlie

Message to #general → All three receive.

Connection idle?
Send ping, expect pong.

No pong? Connection dead. Reconnect.

Connection drops (network blip).
Client should auto-reconnect.
Resume where it left off.

WebSockets are stateful.
Each connection lives on specific server.

Load balancer sends user to Server A.
Push message needs to go to Server A.
How does Server B know about the user?

1. Sticky sessions
   Same user often goes to the same server.

2. Pub/Sub backend (Redis)
   All servers subscribe to message channel.
   Message published → All servers receive.
   Server with that user sends to client.

3. Managed services
   Let AWS, Pusher, etc. handle it.

Server → Client (one direction).
Simpler than WebSocket.
Good for notifications, feeds.

Use when: Server needs to push updates, and the client doesn't need to send messages.

Client keeps request open.
Server responds when data available.
Client immediately makes new request.

Fallback when WebSocket not available.

Real-time bidirectional: WebSocket
One-way server → client push: SSE
Maximum compatibility: Long polling fallback

Networks are unreliable.
Usually implement reconnection logic.

Connection looks open but is dead.
Ping/pong detects this.

Sending unnecessary updates.
Causing client performance issues.

Send what's needed.

WebSocket after handshake doesn't re-auth.
Authenticate during handshake.
Check permissions on each message.