Loading...
Zashly
A real-time social platform with group chat, direct messaging, video calling, and ephemeral stories. Built with Socket.IO for messaging and Stream Video SDK for WebRTC calls.
Core Engineering Achievement
Integrated Socket.IO for bidirectional messaging and Stream Video SDK for WebRTC peer-to-peer video calls within a unified React client.
System Interface & Feature Tour
zashly.vercel.app
Messaging
Click for Fullscreen
Production Stats
0
Core Features0
MongoDB Collections0+
Git Commits0
Realtime ProtocolsSocket.IO Rooms
Messaging
Stream SDK (WebRTC)
Video
Zustand
State
The Challenge
Building a chat app is straightforward. Building one with video calls, stories, and real-time presence — all sharing the same React client and backend — requires careful separation of concerns between Socket.IO events, REST API calls, and the Stream Video SDK lifecycle.
Project Goals
- Implement room-based Socket.IO messaging with persistent history in MongoDB.
- Integrate Stream Video SDK for peer video calls without managing raw WebRTC signaling manually.
- Track online presence across all connected clients using socket connection/disconnection events.
Technology Stack
frontend
backend
database
infrastructure
tooling
System Architecture
Client Layer
React with Zustand for global socket state. Stream Video SDK's React hooks manage the call UI. Tailwind CSS for responsive layout.
Application Layer
Node.js + Express for REST endpoints. A separate Socket.IO server instance runs alongside Express, sharing the same HTTP server. JWT validates socket connection at handshake.
Data Layer
MongoDB with three main collections: users, messages (indexed on conversationId), and stories (filtered by createdAt TTL).
Performance & Security Architecture
⚡ Performance & Scalability
Socket.IO rooms ensure events are only broadcast to relevant users, not all connected clients. Message history uses MongoDB's conversationId index for efficient fetch.
🔒 Security & Access Control
JWT token is validated during Socket.IO handshake before the connection is accepted. Unauthenticated socket connections are rejected at the server.
Engineering Decisions & Trade-offs
Stream Video SDK over raw WebRTC
Reasoning
Implementing WebRTC from scratch means managing SDP offers, ICE candidates, TURN server configuration, and reconnection logic. Stream handles all of this and provides tested React hooks.
Trade-off
Introduces a third-party dependency and requires a Stream account with API keys. Adds ongoing cost if scaled to many concurrent calls.
Zustand for socket state
Reasoning
The socket connection is created once but needs to be accessible from the chat list, message thread, and presence indicator — all in different parts of the component tree. Zustand avoids prop drilling and Context re-render issues.
Trade-off
Requires discipline to keep socket slice separate from UI state to avoid accidental re-renders on every socket event.
Key Results & Production Impact
- Working platform with group chat, direct messaging, video calls, stories, and online presence — all functional in the same session.
- Socket listeners are properly cleaned up in useEffect return functions — no duplicate messages on re-render.
- Video call flow (invite → join → end → cleanup) works end-to-end using Stream's SDK.
Engineering Takeaways & Lessons Learned
When integrating two real-time systems (Socket.IO + WebRTC SDK), isolate each one in its own state slice and define clear ownership. Letting them share state leads to race conditions that are extremely hard to debug.