harshaSystems / Full-stack application
WebChat
An offline-capable chat application with React, Dexie/IndexedDB, authenticated FastAPI WebSockets, queued server processing, room delivery, and reconciliation APIs.
View repository01 / COMPONENTS & DATA FLOW
Inside the system.
- 01React + local pending record
- 02Authenticated WebSocket
- 03Message persistence + room fanout
- 04Reconnect + sync
Local-first message state
Dexie stores messages with pending, synced, or failed status and temp IDs. The frontend persists outgoing messages while offline and attempts reconciliation when connectivity returns.
Connection-aware delivery
The FastAPI ConnectionManager maps users to multiple connection IDs, tracks room membership, queues message work, and handles chat, read receipts, and call-signaling events.
Reconciliation path
POST /sync accepts offline messages, returns temp-to-server ID mappings, and retrieves up to 100 new messages from the user’s rooms since a supplied sync time.
02 / IMPLEMENTATION DECISIONS
Why it works this way.
Delivery and storage are distinct
A WebSocket gives timely updates, while IndexedDB and the sync API preserve local work across disconnects. Client synchronization errors use exponential backoff capped at 30 seconds.
Deduplication is currently heuristic
The sync endpoint checks matching sender, room, and content within a two-second window. That is a practical heuristic, not a durable idempotency-key guarantee.
03 / SCOPE & TRADEOFFS
The implementation boundary.
The connection manager uses in-process maps and queues. Scaling delivery across multiple backend instances requires an additional shared coordination or fanout layer.
04 / READ THE IMPLEMENTATION