Build a real-time collaborative feature
Real-time is where full-stack gets genuinely hard, and genuinely impressive. You build a collaborative feature (shared editing, a live board, or presence-rich updates) that stays consistent when several people touch it at once, survives a dropped connection, and feels instant.
What you'll build
A live collaborative feature over WebSockets/SSE with optimistic UI, presence, and sane conflict handling, deployed, and documented with an honest account of your consistency trade-offs.
See how we teach, before you sign up
You don't just get code dumped on you. Every starter file and every solution is explained line-by-line, in plain English. Here's one real file from this project:
export interface Op {
opId: string; // client-generated; matches the server echo
roomId: string;
authorId: string;
// The change itself, for a list: an add/remove; for text: a CRDT update.
kind: 'add' | 'remove' | 'update';
payload: unknown;
ts: number; // client clock, for ordering hints only
}
export interface PresenceMember {
userId: string;
name: string;
lastSeen: number; // updated by heartbeat; used to expire ghosts
}Reading this file
interface Op {A single agreed message shape both clients and server use, so everyone interprets a change the same way over the wire.opId: stringA client-generated id that lets a client recognize the echo of its own edit and avoid applying it twice.kind: 'add' | 'remove' | 'update'Tags what the change does so the receiver knows how to apply it without guessing.lastSeen: numberA timestamp refreshed by heartbeats, used to drop 'ghost' users whose tab closed without saying goodbye.
The wire format. A client-generated opId is what lets a client recognize its own echo.
That's 1 of 10 explained code blocks in this single project.
The build, milestone by milestone
- 1
Establish the channel
5 guided stepsNetworks drop. A real-time feature that doesn’t reconnect and resync silently shows stale state, worse than no real-time at all.
- 2
Sync optimistically
5 guided stepsWaiting for a server round-trip on every keystroke feels laggy. Optimistic updates make collaboration feel instant, but only if you reconcile correctly.
- 3
Show presence
5 guided stepsPresence is what makes a shared space feel shared. It also prevents users from blindly stomping on each other’s in-progress work.
- 4
Handle the messy cases
5 guided stepsDemos work with one user. Real collaboration is defined by what happens when two people edit the same thing at the same instant.
- 5
Observe the channel & bound its cost
4 guided stepsReal-time systems fail quietly, a slow channel or a message storm looks fine until users complain. You need numbers, and you need to know that 10k concurrent connections won’t bankrupt you.
- 6
Write the runbook
4 guided stepsWhen the channel breaks at 2am, future-you (or a teammate) needs a checklist, not a debugging session from scratch. A runbook is what makes a feature operable.
What's inside when you start
You'll walk away with
This is portfolio-grade. Build it free.
Sign up to unlock every milestone step-by-step, the code skeletons, full reference solutions, and checkable tasks, with your progress saved as you build.
Start building