Case Study · Real-Time Application
Bharat Chat Application
Real-time messaging built on sockets, sessions and clean state.
- React.js
- Node.js
- Express.js
- MongoDB
- Socket.io
- JWT
What it is
Bharat Chat is a full-stack messaging application built on the MERN stack. It pairs a persistent REST layer for users and conversation history with a Socket.io transport for live delivery, so messages appear instantly while remaining durable in MongoDB.
The objective
HTTP request/response alone cannot deliver messages as they happen, and socket connections need to be tied to an authenticated identity rather than an open tab.
- HTTP request/response alone cannot deliver messages as they happen.
- Socket connections need to be tied to an authenticated identity, not just an open tab.
- Live UI state and stored history have to stay in agreement after reconnects.
How it was solved
A Socket.io layer runs alongside the Express REST API so live events and persistence stay separate concerns, with the authenticated user attached to the socket handshake and history merged into the same client state shape.
- Added a Socket.io layer alongside the Express REST API so live events and persistence stay separate concerns.
- Attached the authenticated user to the socket handshake so events can be scoped per conversation.
- Loaded history from MongoDB on mount and merged incoming socket events into the same client state shape.
Key features
Real-time messaging
One-to-one delivery over a Socket.io transport.
Authenticated sessions
JWT-based sessions scoped per user and carried into the socket handshake.
Persistent history
Conversations stored in MongoDB and reloaded on mount.
Conversation dashboard
A dashboard layout for switching between active chats.
Technology
Frontend
- React.js
- Tailwind CSS
Backend
- Node.js
- Express.js
Database
- MongoDB
- Mongoose
Other
- Socket.io
- JWT
- REST API
Development approach
- Socket.io layer added alongside the Express REST API to separate transport from storage.
- Authenticated user attached to the socket handshake so events scope per conversation.
- History loaded from MongoDB and merged into the same client state shape as live events.
Interface decisions
- Messages appear optimistically and reconcile with the stored record.
- Conversation list and thread work side by side on desktop, stacked on mobile.
Challenges & solutions
Live UI state and stored history disagreed after a reconnect.
One client state shape for fetched history and socket events, merged by message id.
Socket events could be received by unintended clients.
Events scoped to conversation rooms after identifying the user at handshake.
