[SPIKE-003] Real-time Updates (WebSocket vs SSE) #3

New Issue

cardosofelipe · 2025-12-29T03:50:15Z

cardosofelipe commented

2025-12-29 03:50:15 +00:00

Objective

Determine the best approach for real-time updates from agents to the frontend.

Options to Evaluate

WebSocket - Full duplex, more complex
Server-Sent Events (SSE) - Simpler, unidirectional
Hybrid - SSE for updates, WebSocket for bidirectional needs

Key Questions

Do we need bidirectional communication or just server→client updates?
How does each integrate with FastAPI?
What's the connection management overhead?
How do we handle reconnection and missed messages?
How do we scale with many concurrent projects?

Research Areas

FastAPI WebSocket support and patterns
FastAPI SSE (using sse-starlette or similar)
Connection management at scale
Message ordering and delivery guarantees

Expected Deliverables

Comparison matrix of approaches
Proof-of-concept for recommended approach
ADR documenting the decision

Acceptance Criteria

Can stream agent output to frontend in real-time
Handles disconnection/reconnection gracefully
Works with authentication (JWT)
Scalable to 10+ concurrent projects

Labels

spike, architecture, realtime

## Objective Determine the best approach for real-time updates from agents to the frontend. ## Options to Evaluate 1. **WebSocket** - Full duplex, more complex 2. **Server-Sent Events (SSE)** - Simpler, unidirectional 3. **Hybrid** - SSE for updates, WebSocket for bidirectional needs ## Key Questions 1. Do we need bidirectional communication or just server→client updates? 2. How does each integrate with FastAPI? 3. What's the connection management overhead? 4. How do we handle reconnection and missed messages? 5. How do we scale with many concurrent projects? ## Research Areas - [ ] FastAPI WebSocket support and patterns - [ ] FastAPI SSE (using sse-starlette or similar) - [ ] Connection management at scale - [ ] Message ordering and delivery guarantees ## Expected Deliverables - Comparison matrix of approaches - Proof-of-concept for recommended approach - ADR documenting the decision ## Acceptance Criteria - [ ] Can stream agent output to frontend in real-time - [ ] Handles disconnection/reconnection gracefully - [ ] Works with authentication (JWT) - [ ] Scalable to 10+ concurrent projects ## Labels `spike`, `architecture`, `realtime`

cardosofelipe added the architecture priority:high spike labels 2025-12-29 03:54:32 +00:00

cardosofelipe commented

2025-12-29 04:08:56 +00:00

Spike Completed

Research completed and documented in:

Spike Document: docs/spikes/SPIKE-003-realtime-updates.md
ADR: docs/adrs/ADR-002-realtime-communication.md

Key Findings:

90%+ of real-time communication is server-to-client (unidirectional)
SSE provides automatic reconnection and native HTTP compatibility
WebSocket needed only for bidirectional chat with agents
Use Redis Pub/Sub for event distribution across instances

Decision:

Adopt SSE as primary real-time transport with WebSocket reserved for bidirectional chat. Use Redis Pub/Sub for event distribution.

This spike can be closed.

## Spike Completed Research completed and documented in: - **Spike Document:** `docs/spikes/SPIKE-003-realtime-updates.md` - **ADR:** `docs/adrs/ADR-002-realtime-communication.md` ### Key Findings: - 90%+ of real-time communication is **server-to-client** (unidirectional) - SSE provides **automatic reconnection** and native HTTP compatibility - WebSocket needed only for **bidirectional chat** with agents - Use **Redis Pub/Sub** for event distribution across instances ### Decision: Adopt SSE as primary real-time transport with WebSocket reserved for bidirectional chat. Use Redis Pub/Sub for event distribution. This spike can be closed.

cardosofelipe closed this issue

2025-12-29 12:45:55 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: cardosofelipe/syndarix#3