01 — The Problem
Users want messaging that feels genuinely instant
Most beginner chat apps use polling — fetching the server every few seconds. This causes visible lag, high server load, and a poor UX. The goal was to build something that felt like WhatsApp using persistent WebSocket connections, with typing indicators, read receipts, and presence — all in real time.
The UI also had to feel premium — not a "tutorial project" — with a glassmorphic dark design matching user expectations set by modern messengers like Telegram.
02 — Research & Discovery
Studying how real messengers handle state
Before writing code I reverse-engineered WhatsApp Web and Telegram Web to identify 4 core mechanics:
01
Persistent WS Connection — Socket.io keeps one TCP connection per user, emitting events both directions instead of polling.
02
Room-based Architecture — Each conversation is a "room". Messages emit only to that room, not broadcast globally.
03
Optimistic UI Updates — Messages appear immediately in the UI while the server confirms delivery in the background.
04
Presence System — Online/offline status and typing indicators tracked server-side via socket lifecycle events.
03 — Design Decisions
Glassmorphic dark UI — premium, not basic
Glassmorphism
Chat bubbles use backdrop-filter blur with translucent backgrounds — depth without heavy shadows.
Typing Indicator
Animated 3-dot pulse that appears when the other party types, with 1.5s debounce to prevent spam.
Live Presence
Green pulsing dot on avatars showing real-time online status synced via socket disconnect events.
Mobile-First
Two-panel desktop layout collapses to single panel on mobile with smooth slide transitions.
04 — Technical Architecture
Socket.io + MongoDB + Room-based messaging
Client Browser
Vanilla JS + Socket.io-client
Vanilla JS + Socket.io-client
⟷ WebSocket
Node.js Server
Express + Socket.io
Express + Socket.io
⟷ Mongoose
MongoDB Atlas
messages · users · rooms
messages · users · rooms
// Emit message and persist to DB
socket.on('send_message', async ({ roomId, text, senderId }) => {
const msg = await Message.create({ roomId, text, senderId });
io.to(roomId).emit('receive_message', msg);
});
// Typing indicator with debounce
socket.on('typing', ({ roomId }) => {
socket.to(roomId).emit('user_typing', socket.userId);
});05 — Challenges & Solutions
What went wrong — and how I fixed it
🔴 Problem: Messages arriving out of order at high frequency.
✅ Solution: Added
createdAt timestamp to every message and sorted client-side on render rather than trusting socket event order.🔴 Problem: User reconnects after network drop and misses messages sent while offline.
✅ Solution: On reconnect, client emits
sync_messages with the last seen message ID. Server returns all messages after that ID.🔴 Problem: Typing indicator kept showing after sender stopped typing.
✅ Solution: 1.5s
setTimeout debounce on client — if no keypress in 1.5s, emit stopped_typing to clear the indicator.06 — Results
What actually shipped
<80ms
Avg message delivery latency over LAN
100%
Real-time — zero polling, all WebSocket
4 features
Typing, presence, rooms, message sync
8 weeks
Idea to production-ready build
Key Takeaway: Real-time state is a distributed systems problem. Managing socket lifecycle events is as important as the feature logic itself.
