Web Development Project
Real-Time Chat App
A chat app is the standard way to learn real-time web development, because it forces you to handle state that arrives without being requested. The hard parts are not the messages — they are reconnection, ordering, presence and what the UI does when the network drops.
The brief
Build a chat with multiple rooms, live message delivery, who-is-online presence and persistent history. It must recover gracefully when a connection drops, which will happen constantly on mobile.
What it demonstrates
That you can handle stateful connections and design for failure — a step up from request-response CRUD.
What "done" looks like
Build all of these and the project is finished. Anything past that is in the stretch goals.
- Multiple rooms a user can join and leave
- Messages delivered live to everyone in the room
- Persistent history loaded on join
- Presence — who is online right now
- Typing indicators
- Automatic reconnection that does not duplicate or lose messages
How to build it
- 1
Model rooms, users and messages
Get the schema right first — message ordering and history pagination both depend on it.
- 2
Open a WebSocket connection
Establish the socket, authenticate it, and define a small message protocol with a type field.
- 3
Broadcast within a room
Track which sockets are in which room server-side and fan out only to those.
- 4
Persist and paginate history
Store every message and load the last page on join. Use cursor pagination — offsets shift as new messages arrive.
- 5
Handle reconnection
On reconnect, fetch anything missed since the last seen message id. This is the hardest and most important step.
- 6
Add presence and typing
Heartbeats with a timeout for presence; debounce typing events so you are not sending one per keystroke.
- 7
Secure it
Authenticate the socket, authorise every room join server-side, and escape message content on render.
- 8
Test the unhappy paths
Kill the network mid-conversation. Open two tabs. Send while disconnected. That is where the bugs are.
Once it works
Only after the definition of done is met. Half-finished ambition reads worse than a small finished thing.
- Add direct messages and read receipts
- Scale to several server processes with a Redis pub/sub layer
- Add file and image sharing with client-side compression
Frequently Asked Questions
WebSockets or Server-Sent Events?
WebSockets, because chat is bidirectional. SSE is simpler and excellent for server-to-client streams such as notifications or live scores, but it cannot carry messages upward, so you would need a second channel anyway.
What is the hardest part?
Reconnection. A phone loses connectivity constantly, and your client must reconnect, re-authenticate and fetch anything it missed without duplicating messages. Getting that right is the difference between a demo and something usable.
Do I need Redis?
Only once you run more than one server process — then you need a pub/sub layer so a message sent to one instance reaches clients connected to another. On a single instance, skip it and add it when you scale, which is a good story for an interview.