Architecture
Enclavr uses a modular architecture with separate repositories for frontend, server, and infrastructure.
System Overview
┌─────────────────────────────────────────────────────────────────┐
│ Browser │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────────────┐ │
│ │ WebRTC │ │ WebSocket │ │ REST API │ │
│ │ (Voice) │ │ (Chat/DM) │ │ (HTTP) │ │
│ └──────┬───────┘ └──────┬───────┘ └──────────┬───────────┘ │
└─────────┼──────────────────┼────────────────────┼─────────────┘
│ │ │
▼ ▼ ▼
┌─────────────────────────────────────────────────────────────────┐
│ Coturn (TURN Server) │
│ Ports: 3478, 49152-49172 │
└─────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ Frontend │
│ Next.js 16 (Port 3000) │
└─────────────────────────────┬───────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ Server │
│ Go 1.25 (Port 8080) │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────────────┐ │
│ │ REST API │ │ WebSocket │ │ gRPC (TLS) │ │
│ │ 230+ routes │ │ Hub + DM │ │ 4 services │ │
│ └──────────────┘ └──────┬───────┘ └──────────────────────┘ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────────────┐ │
│ │ WebRTC │ │ WebAuthn │ │ OAuth/OIDC │ │
│ │ Signaling │ │ FIDO2 │ │ Providers │ │
│ └──────────────┘ └──────────────┘ └──────────────────────┘ │
└────────────────────────────┼───────────────────────────────────┘
│
┌──────────────┼──────────────┐
▼ ▼ ▼
┌────────────┐ ┌────────────┐ ┌────────────┐
│ PostgreSQL │ │ Redis │ │ STUN │
│ :5432 │ │ :6379 │ │ Google │
└────────────┘ └────────────┘ └────────────┘
Project Structure
Enclavr uses git submodules:
| Repository | Description |
|---|---|
| enclavr/enclavr | Root monorepo |
| enclavr/frontend | Next.js frontend |
| enclavr/server | Go backend |
| enclavr/infra | Docker deployment |
Data Flow
Authentication Flow
- User submits credentials to Frontend
- Frontend calls Server
/api/auth/login - Server validates and returns JWT + refresh token
- Frontend stores tokens and includes JWT in subsequent requests
Chat Flow
- User sends message via Frontend
- Frontend sends to Server via REST API
- Server stores in PostgreSQL
- Server broadcasts to room via WebSocket
- Other users receive real-time update
Voice Flow
- User joins voice channel
- Frontend connects to Server WebSocket (
/api/voice/ws) - Server performs ICE handshake with STUN/TURN
- Peers connect directly via WebRTC
- Audio streams peer-to-peer
Communication Channels
| Channel | Protocol | Port | Purpose |
|---|---|---|---|
| REST API | HTTP/HTTPS | 8080 | CRUD operations, auth, admin |
| WebSocket | WS/WSS | 8080 | Real-time chat, DM, presence, voice signaling |
| gRPC | HTTP/2 + TLS | 8081 | Service-to-service communication (Auth, Room, Message, User) |
| WebRTC | DTLS/SRTP | P2P | Voice/video media streams |
| WebAuthn | HTTP | 8080 | Passkey/FIDO2 authentication ceremonies |
gRPC Services
The server exposes a gRPC interface defined in api/enclavr.proto with 4 services:
| Service | Methods |
|---|---|
| AuthService | Register, Login, RefreshToken, GetMe |
| RoomService | GetRooms, CreateRoom, GetRoom, JoinRoom, LeaveRoom |
| MessageService | GetMessages, SendMessage, UpdateMessage, DeleteMessage, SearchMessages |
| UserService | SearchUsers, GetProfile |
Scaling
- WebSocket scaling: Redis pub/sub for cross-server message broadcasting
- Rate limiting: Redis-backed distributed rate limiting (sliding window + per-endpoint)
- Database: Connection pooling with GORM (10 idle, 100 max connections)
- Static assets: CDN-ready frontend (static export)
- gRPC: TLS-secured inter-service communication for microservice architecture
- Circuit breaker: Pattern for external service resilience