More project photos (3)
The problem
Every team runs on chat, and building one is the classic way to learn real-time systems properly: persistent connections, message ordering, presence, typing indicators and history pagination all have to work together. Most student chat projects are single-room toys with messages that vanish on refresh. This one is built like a real product — named rooms with descriptions and invite links, per-room message history stored in the database, typing indicators, emoji reactions, full-text message search, online/away presence, unread badges for rooms with new messages, and member lists. The backend uses Socket.IO rooms on Node.js with Redis pub/sub so it scales beyond one process, and the protocol (events, acknowledgements, reconnection) is documented in the report.
Joins rooms, sends messages, sees typing indicators and presence.
Follow the working sequence
How it works
- The client connects via Socket.IO and authenticates with a JWT; the server loads the user's room memberships and unread counts.
- Joining a room subscribes the socket to that room; the server sends the latest page of message history and marks the room read.
- Sending a message emits a
messageevent; the server validates, persists it, and broadcasts to the room via Redis pub/sub so all server instances deliver it. - The sender gets an acknowledgement with the stored message ID; clients render optimistically and reconcile on ack.
- Typing indicators and reactions travel as lightweight ephemeral events that are not persisted; presence heartbeats update the online list.
- On reconnect, the client replays missed messages by requesting history after its last known message ID.
Tech stack:
- Node.js, Express
- Socket.IO (WebSocket transport)
- Redis (pub/sub + presence)
- PostgreSQL (message history)
- JWT authentication
- HTML/CSS/JavaScript UI
- Docker (deployment)
- Nginx (reverse proxy)
| Parameter | Value |
|---|---|
| Transport | WebSocket (Socket.IO) with polling fallback |
| Message latency | Under 100 ms on LAN (design target) |
| History | Paginated, 50 messages per page |
| Search | Full-text over room history |
| Presence | Heartbeat-based online/away |
| Scaling | Redis pub/sub across Node instances |
| Auth | JWT with room membership checks |
| Deployment | Docker Compose (app + Redis + PostgreSQL) |
Project features
- [Real-time messaging] Messages appear instantly for all room members over WebSocket connections with delivery acknowledgements.
- [Chat rooms] Named rooms with descriptions, invite links and per-room unread badges; switching rooms loads that room's history.
- [Typing indicators] Live "X is typing…" indicators with automatic timeout, implemented as ephemeral socket events.
- [Emoji reactions] Per-message reactions with counts and per-user toggling, synced across clients.
- [Message search] Full-text search across the current room's history with instant client-side filtering.
- [Presence system] Online/away indicators, member lists and join/leave activity in every room.
- [Persistent history] Messages stored per room in the database with pagination, so history survives restarts and new devices.
What is included
- Complete full-stack source code (client + server)
- Socket.IO messaging protocol implementation (rooms, acks, reconnect)
- Typing, reactions, search and presence features
- Docker Compose deployment setup
- Deployment guide (VPS, HTTPS, scaling notes)
- Project report PDF (background, WebSocket theory, protocol design, data model, testing)
- PPT presentation for final review
- Viva Q&A preparation document (Socket.IO rooms, acks, Redis pub/sub, ordering, scaling)
Limitations & prerequisites
- Text and emoji only in this build — file/image attachments are listed as future scope.
- Sub-100-ms latency is a design target, stated honestly — the report documents the load test actually run for the order.
- Message ordering relies on server timestamps; clocks are assumed synchronized (NTP) across instances.
- No end-to-end encryption in this build; transport is TLS-terminated at Nginx (E2EE is future scope).
- Push notifications for offline users are out of scope.
Frequently Asked Questions
Why Socket.IO instead of raw WebSockets?
Socket.IO adds rooms, automatic reconnection, fallback transports and acknowledgements on top of WebSockets — exactly the primitives a chat app needs, without hand-rolling them.
How does the sender know a message arrived?
The server acknowledges each message event with the persisted message ID; the client shows a pending state until the ack arrives, then marks it sent.
What happens on disconnect?
The client reconnects automatically with backoff and requests any messages after its last known ID, so nothing is missed; presence flips the user to away in the meantime.
How is message history stored?
Per-room tables in PostgreSQL with indexes on (room, timestamp); the client paginates 50 at a time when scrolling up.
Can this scale to many users?
The Redis pub/sub layer lets multiple Node instances share room traffic, and the report documents the horizontal-scaling design with its limits.
Is this project suitable for a final-year project?
Yes — for Computer Science, IT and Web Development programs. It demonstrates real-time protocols, full-stack architecture, data modeling and a genuinely usable product. Suitable for B.E./B.Tech final-year projects in Computer Science, IT and Web Development.
Components & software requirements
- Node.js, Express
- Socket.IO (WebSocket transport)
- Redis (pub/sub + presence)
- PostgreSQL (message history)
- JWT authentication
- HTML/CSS/JavaScript UI
- Docker (deployment)
- Nginx (reverse proxy)
Delivery information
Built-to-order project. Delivery timeline is shared after order confirmation based on current queue.
Support terms
Complete documentation, setup guide, and viva preparation included. Support for setup and explanation provided.
Download free synopsis (PDF)
Enter your name and WhatsApp number — the synopsis PDF downloads immediately. We may send occasional project updates on WhatsApp; no spam.