WebSockets

tags : Web Development, SSE, WebRTC, HTTP, NAT, Network Programming

Tools

Server

Implementation

snapview/tungstenite-rs

Experimental tools

joewalnes/websocketd: Turn any program that uses STDIN/STDOUT into a WebSocket server. Like inetd, but for WebSockets.
networkprotocol/netcode
GitHub - neondatabase/wsproxy : tunnel TCP traffic over WebSockets

Different approaches

Notification/Invalidation

WS Message Example: {“entity”: “todos”, “id”: “123”, “action”: “updated”}
Client Action: Invalidates relevant client cache (e.g., React Query queryKey), triggers HTTP refetch.
Key Characteristic: WS signals change; data fetched via standard HTTP.
Primary Use Case: Keeping cached data fresh by leveraging existing API endpoints, data consistency.

Pushing Full Data

WS Message Example: {“entity”: “user”, “id”: “456”, “payload”: {“name”: “Jane”, “status”: “active”}}
Client Action: Directly updates client cache with the received payload.
Key Characteristic: WS delivers complete, new state of a resource.
Primary Use Case: Faster UI updates (no extra HTTP), when server can easily send full state.

Pushing Partial Data (Deltas)

WS Message Example: {“entity”: “document”, “id”: “doc1”, “delta”: {“title”: “New Title Only”}}
Client Action: Merges delta with existing cached data for the resource.
Key Characteristic: WS delivers only changed fields; minimizes bandwidth.
Primary Use Case: Efficient updates for large objects or frequent small changes.

Event-Driven Actions

WS Message Example: {“event”: “user_typing”, “chatId”: “general”} or {“event”: “new_mail_count”, “count”: 3}
Client Action: Triggers UI changes (e.g., “typing…” indicator) or other non-data-state logic.
Key Characteristic: WS communicates occurrences/signals, not necessarily resource state changes.
Primary Use Case: Real-time UI feedback, notifications, triggering client-side logic.

RPC (Remote Procedure Call)

WS Message Example:
- Client: {“id”: “req1”, “method”: “createItem”, “params”: {“name”: “New”}}
- Server: {“id”: “req1”, “result”: {“id”: “xyz”, …}}
Client Action: Client sends commands, server executes and sends results/errors back.
Key Characteristic: Bidirectional command-response interaction over a persistent WS connection.
Primary Use Case: Interactive operations, stateful interactions, potentially replacing some HTTP calls.

Streaming Data

WS Message Example: {“type”: “price_update”, “symbol”: “XYZ”, “price”: 150.75, “ts”: …} (repeatedly)
Client Action: Continuously processes incoming data flow (display, chart, aggregate).
Key Characteristic: Continuous, often high-frequency, flow of new, independent data points.
Primary Use Case: Live feeds (stocks, logs, sensor data), real-time monitoring, analytics.

Difference with SSE

Feature Comparison Matrix

Feature/Aspect	WebSockets	Server-Sent Events (SSE)
Communication Direction	Full-duplex (bidirectional)	One-way (server-to-client)
Message Ordering	Guaranteed message ordering ✓	Ordered by design
Connection Persistence	Persistent connections ✓	Persistent, but one-way
Session Management	Sticky sessions supported ✓	Uses HTTP cookies for sessions
Header Support	Cannot add headers (e.g., for auth/cookies) ✗	Full HTTP header support ✓
Infrastructure Requirements	Significant time and infrastructure investment needed ✗	Works with standard HTTP infrastructure ✓
Cost-effectiveness	Can be cheap with right infrastructure (e.g., Cloudflare)	Generally cost-effective
Replacement Availability	No good modern replacement available ✗	Serves as alternative for one-way communication

Optimal Use Cases

WebSockets

Real-time chat applications requiring bidirectional communication
Live gaming with immediate user interactions
Collaborative editing tools needing guaranteed message ordering
Financial dashboards with real-time data updates
Applications leveraging Cloudflare or similar modern infrastructure
Scenarios where sticky sessions and guaranteed message ordering are critical

Server-Sent Events (SSE)

News feeds and social media timelines
Stock tickers and market data displays
Status updates and notifications
One-way, server-to-client real-time updates
Applications where HTTP header support is necessary
Scenarios where bidirectional communication is not required

HTTP/2 or HTTP/3

REST or GraphQL APIs requiring efficient connections
Applications with multiple, parallel data requests
Content delivery requiring optimized bandwidth usage
Modern web applications without strict real-time requirements
Scenarios where standard HTTP semantics are preferred

Implementation Recommendations

For WebSockets Implementation

Leverage modern infrastructures like Cloudflare Workers
Focus on use cases requiring persistent, bidirectional connections
Implement custom solutions for authentication limitations
Reserve for scenarios where benefits outweigh engineering challenges
Be prepared for limited future improvements from standards bodies

For SSE Implementation

Combine with HTTP/2 or HTTP/3 for improved performance
Utilize for simpler, server-driven real-time updates
Take advantage of standard HTTP header support for authentication
Consider as primary option for one-way communication needs
Benefit from ongoing standards support and development

Links