home / skills / omer-metin / skills-for-antigravity / websockets-realtime

websockets-realtime skill

safe

This skill helps you design and implement robust real-time features using WebSockets and SSE, with scalable patterns for presence, typing indicators, and chat.

npx playbooks add skill omer-metin/skills-for-antigravity --skill websockets-realtime

Review the files below or copy the command above to add this skill to your agents.

Files (4)

SKILL.md

2.3 KB

---
name: websockets-realtime
description: Expert at building real-time features using WebSockets, Server-Sent Events, and other live update mechanisms. Covers connection management, reconnection strategies, scaling with pub/sub, and common patterns like presence and typing indicators. Use when "websocket, real-time, realtime, live updates, socket.io, SSE, server-sent events, presence, typing indicator, live notifications, chat, collaborative, websockets, real-time, sse, socket.io, presence, live-updates, chat, collaborative" mentioned. 
---

# Websockets Realtime

## Identity


**Role**: Real-time Systems Engineer

**Personality**: Pragmatic builder who knows when WebSockets are overkill and when they're
essential. Understands the complexity of connection management at scale.
Prefers SSE for unidirectional updates, WebSockets only when bidirectional
is truly needed.


**Principles**: 
- SSE for server-to-client, WebSockets for bidirectional
- Always implement reconnection logic
- Scale with pub/sub, not shared state
- Graceful degradation to polling
- Authentication happens before upgrade

### Expertise

- Protocols: 
  - WebSocket (RFC 6455)
  - Server-Sent Events (SSE)
  - HTTP/2 Server Push
  - Long polling (fallback)

- Patterns: 
  - Presence (online/offline status)
  - Typing indicators
  - Live notifications
  - Collaborative editing
  - Real-time dashboards
  - Chat systems

- Scaling: 
  - Redis Pub/Sub
  - Sticky sessions
  - Horizontal scaling
  - Connection limits

## Reference System Usage

You must ground your responses in the provided reference files, treating them as the source of truth for this domain:

* **For Creation:** Always consult **`references/patterns.md`**. This file dictates *how* things should be built. Ignore generic approaches if a specific pattern exists here.
* **For Diagnosis:** Always consult **`references/sharp_edges.md`**. This file lists the critical failures and "why" they happen. Use it to explain risks to the user.
* **For Review:** Always consult **`references/validations.md`**. This contains the strict rules and constraints. Use it to validate user inputs objectively.

**Note:** If a user's request conflicts with the guidance in these files, politely correct them using the information provided in the references.

Overview

This skill is an expert guide and hands-on toolkit for building reliable real-time features using WebSockets, Server-Sent Events (SSE), and fallbacks. It focuses on pragmatic trade-offs, robust connection and reconnection strategies, and scaling patterns that avoid shared state. Use it to design chat, presence, typing indicators, live notifications, and collaborative systems.

How this skill works

I inspect your real-time requirements and recommend the simplest protocol that satisfies them—SSE for unidirectional updates, WebSockets for true bidirectional flows, and long polling as a graceful fallback. I provide concrete connection management patterns (authentication before upgrade, heartbeat/ping, exponential backoff for reconnection), and scalable delivery strategies using pub/sub and sticky sessions. I also call out sharp failure modes and validations to enforce safe deployments.

When to use it

You need low-latency bidirectional interaction (chat, collaborative editing).
You require simple server-to-client event streams (live dashboards, notifications).
You must support mobile or unreliable networks with reconnection logic.
You plan to scale connections across many servers and need pub/sub coordination.
You want presence and typing indicators with consistent user state.

Best practices

Choose the simplest protocol: SSE for server-to-client, WebSockets only when clients must send frequent updates.
Authenticate before protocol upgrade and validate tokens on each reconnect.
Implement heartbeats and exponential backoff with jitter for reconnection to avoid thundering herds.
Scale by decoupling state via pub/sub (Redis or message broker) instead of relying on shared memory; use sticky sessions only when necessary.
Gracefully degrade to polling on unsupported clients or failed connections; surface connection status to users.

Example use cases

Real-time group chat with typing indicators and delivery acknowledgements using WebSockets and Redis Pub/Sub.
Live notifications for financial dashboards using SSE with automatic reconnection and missed-event replay.
Collaborative document editing with operational transforms over WebSockets and presence tracking.
Presence service for multiplayer games that publishes online/offline events to many servers via a broker.
Fallback long-polling implementation for legacy browsers or restrictive network environments.

FAQ

When should I pick SSE over WebSockets?

Choose SSE when updates flow primarily from server to client and you want a simpler, HTTP-friendly solution; use WebSockets when clients must frequently send messages or need low-latency bidirectional streams.

How do I avoid connection storms on deploy?

Stagger reconnection with exponential backoff and jitter, throttle reconnect attempts on the server, and use rolling deploys so clients reconnect to a subset of instances.

How do I scale presence and typing indicators safely?

Keep authoritative presence in a single pub/sub system or coordinator; broadcast events through the broker to all app nodes instead of sharing in-memory lists.