Building Pixel Room — a Real-Time Collaborative Whiteboard (Excalidraw Clone)

Vivek — Thu, 09 Jul 2026 15:25:54 +0000

Why I built this

I wanted to actually understand how tools like Excalidraw and Figma pull off real-time multiplayer canvas sync — so instead of reading about it, I built my own version. Meet Pixel Room: a collaborative whiteboard where you create a room, draw shapes with your crew, and chat live while you sketch.

It's still a work in progress, but the core sync engine works, and I learned a lot building it. Here's the breakdown.

The stack

Turborepo monorepo — shared packages across frontend, backend, and the WebSocket server
React + TypeScript frontend, rendering on HTML5 Canvas
Node.js + Express for the main backend/API
A dedicated ws-server purely for real-time WebSocket traffic
PostgreSQL + Prisma for persistence
BullMQ + Redis for async job processing

Monorepo structure

One decision I'm glad I made early: keeping shared DB logic in packages/db instead of duplicating Prisma client setup inside each app. Both the Express backend and the ws-server import from the same package, so schema changes propagate everywhere without copy-pasting client code.

apps/
  web/          → React frontend
  http-backend/ → Express API
  ws-server/    → WebSocket server
packages/
  db/           → Prisma client + schema, shared
  ui/           → shared components

Real-time sync: the core problem

The obvious naive approach — write every shape straight to Postgres the moment it's drawn — falls apart fast. Every stroke, every drag, every resize would be a DB write. Multiply that by multiple users in a room and you get a database that can't keep up, plus laggy canvas feedback.

The fix: WebSockets for sync, queue for persistence.

When a user draws a shape:

It's broadcast instantly over WebSocket to everyone else in the room (no DB round-trip in the critical path)
The shape event is pushed onto a BullMQ queue backed by Redis
A worker consumes the queue and persists to Postgres asynchronously

This keeps the canvas feeling instant for every connected client while the database gets written to at a sane, batched pace in the background.

The `useWebSocket` hook and pub/sub

One of the trickier bugs I hit was message duplication — the same draw event getting processed twice on a client. Turned out to be a classic React stale-closure issue: my WebSocket message handler was capturing an old version of state due to how refs and setState were timed relative to re-renders.

The fix was building a proper pub/sub pattern around the socket:

One actual WebSocket connection per client, held in a ref (not state, so it survives re-renders)
A subscribe/unsubscribe interface so multiple components (canvas, chat, room presence) can all listen to the same socket without each one attaching its own raw onmessage handler
Handlers dispatch based on event type, so adding new event kinds doesn't mean rewiring the whole hook

This one fix killed the duplication bug and made the codebase much easier to extend — adding chat messages as a new event type on the same socket was trivial afterward.

Canvas: shapes, infinite zoom, resize

The frontend renders directly to an HTML5 <canvas> rather than SVG, for performance with many shapes. Current tool support:

Rectangle, ellipse, triangle, straight line, and freehand draw
Responsive resize handling so the canvas adapts to different screen sizes without shape positions drifting

What's next

Infinite canvas with zoom/pan — panning and zooming into an unbounded space instead of a fixed viewport
Undo/redo — needs an action history stack that stays consistent across clients, not just a local-only undo
More shape types and a proper eraser
Better reconnection handling for flaky connections mid-draw
Room persistence so canvases survive server restarts, not just active sessions

Still very much in progress — but the real-time sync core taught me more about WebSockets, race conditions, and queue-based architecture than any tutorial could have. Happy to go deeper into any part of this (the pub/sub hook, the BullMQ setup, the Prisma schema) in the comments if anyone wants specifics.

I built Stashly — a full-stack content manager with a rich text editor published: false tags: react, node, mongodb, typescript

Vivek — Mon, 25 May 2026 12:29:04 +0000

I wanted one place to save links from YouTube, Twitter, and LinkedIn, and write notes alongside them. Nothing I found did both well, so I built Stashly.

What it does

Save links from YouTube, Twitter, LinkedIn — with auto-embeds
Write and edit notes with a full rich text editor (Tiptap)
Auto-saves notes with a 2s debounce
Share any saved item via a public slug URL
Sign in with Google or GitHub OAuth
Works on mobile (pill nav) and desktop (sidebar) ## Tech stack

Layer	Tech
Frontend	React 19, TypeScript, Vite, TailwindCSS v4
Editor	Tiptap 3
State	Redux Toolkit
Backend	Express 5, TypeScript
Database	MongoDB + Mongoose 9
Auth	Better-Auth (Google / GitHub OAuth)
Validation	Zod

The editor

Tiptap handles the heavy lifting — headings, lists, code blocks, text alignment, color highlights, images, and links. Notes auto-save in the background so you never have to think about it.

Saving content

Paste a YouTube, Twitter, or LinkedIn URL and Stashly stores it with an embed. You can filter your saved content by platform and delete anything you don't need.

Auth

Better-Auth handles OAuth for both Google and GitHub. The session flow was straightforward to set up and the library keeps things out of your way.

Running it locally

# Backend
cd backend
npm install
cp .env.example .env
npm run dev

# Frontend
cd frontend
npm install
npm run dev

You'll need Node 18+ and a MongoDB instance (local or Atlas). The .env.example covers all the required variables — DB URL, Better-Auth secrets, and OAuth credentials for both providers.

What I'd improve

Full-text search across notes and saved links
Browser extension for one-click saving

- Folders or tags for organizing content

Source is on GitHub if you want to take a look or contribute. Feedback welcome.

DEV Community: Vivek