live package provides low-latency real-time message delivery over WebSocket with topic-based publish/subscribe. Itβs designed as a transport layer for instant updates: chat, notifications, collaborative editing, real-time dashboards, and more.
What is Real-time Communication?
In traditional HTTP, the browser sends a request and waits for a response. For new data, you must make another request (polling). Traditional HTTP:Design Principles
| Principle | Description |
|---|---|
| Transport-only | Moves messages, doesnβt interpret state |
| Best-effort | No durability or replay guarantees |
| Topic-based | Scalable, simple pub/sub routing |
| Opaque payloads | Your app defines message schemas |
| Minimal surface | Few types, predictable behavior |
Architecture
- Clients connect via WebSocket
- Sessions created for each connection
- Server subscribes sessions to topics
- Messages published to topics
- All subscribers receive the message
Core Concepts
Server
The Server manages WebSocket connections and pub/sub routing.Session
A Session represents one WebSocket connection. Each has:- Unique ID
- Optional value from authentication
- Send queue for outgoing messages
Message
Messages have a topic and data:Topics
Topics are named channels. Sessions subscribe to topics they care about. When you publish to a topic, all subscribers receive the message.Quick Example
Server (Go):When to Use Live
Use Live when:- You need instant updates (< 100ms latency)
- Multiple clients need to see the same data
- Building interactive features (chat, gaming)
- Pushing data to clients (notifications)
- Updates are infrequent (use polling or SSE)
- You need message durability (use sync package)
- Building a simple REST API
Whatβs Next?
- Quick Start - Build your first live feature
- Server - All server options explained
- Sessions - Connection lifecycle
- Pub/Sub - Topic patterns and publishing