Live presence
Avatars in the workspace header show who's editing what in real time, with last-seen-at fallback for stale tabs.
Case study2026~6 weeksSole developer · architecture, frontend, backend
Sync API
A real-time collaborative API workspace built for developer teams. Postman, reimagined with live presence, shared collections, and auto-generated documentation that updates as you work.
<100mspresence sync latency
1monorepo, 2 services
5+auth types supported
∞collaborators / room
01 — Problem
Postman is great for solo work. Teams need more.
Working on the same API as a teammate is awkward. You message someone a curl command, or commit a collection JSON, or share a Postman link that immediately drifts from what they have locally. Documentation lives in a separate tool. Variables get out of sync. Nobody knows what the staging environment actually looks like right now.
SyncAPI removes the friction by making the workspace itself the source of truth. Open a workspace, see who's currently inside it, edit the same collection in real time, and have the documentation regenerate automatically. No PR, no merge, no broadcast — everyone is already looking at the same thing.
02 — Architecture
One repo, two services, three persistence layers.
Monorepo organized with Turborepo. The Next.js app and the NestJS API share types and schemas via a workspace package, so a contract change is one commit and one PR.
Next.js 14TypeScriptNestJSMongoDBSocket.ioRedisTurborepo
03 — Capabilities
What it actually does.
Request builder
Multiple auth types (bearer, basic, OAuth2, API key, custom), JSON/form/raw bodies, headers, environment variable interpolation.
Shared collections
Drag-and-drop folders, complete request history, per-environment variable scopes, and one-click duplication.
Auto-generated docs
Every saved request becomes a documentation entry. Shareable link, no extra step.
04 — Decisions
Decisions worth keeping a paper trail on.
Why monorepo with Turborepo
Frontend and backend share request/response contracts, environment schemas, and TypeScript types. A monorepo + Turborepo eliminates the drift that an external SDK package would introduce, and lets one PR change both sides atomically.
Why MongoDB over Postgres
Collections, requests, environments, and request logs are document-shaped with deeply variable schemas (headers, body, auth blocks differ per request type). Mongo's flexibility paid off; the relational integrity I gave up was never asked for.
Why Redis backs presence
Presence needs to be ephemeral, fast, and survive pod restarts. A Redis hash per workspace ('who's here, in which collection, last seen at') updates on every heartbeat. Falls back to socket-only state if Redis is unreachable.
Where Socket.io shines
Real-time isn't just chat — it's collection edits, cursor positions in the request builder, and live activity feeds. Socket.io's rooms model maps 1:1 to workspaces, so authorization is enforced once at join time instead of per-event.
05 — Tradeoffs
Where the shape of the problem fought back.
- 01
Render's free-tier cold starts
Deployed to Render's free tier where services sleep after 15min of inactivity. First request after sleep costs ~30s. Fixed with a lightweight ping endpoint hit by an external cron — keeps the dyno warm during expected demo windows.
- 02
Auth across the SSR boundary
NextAuth handles login on the Next.js side, but the NestJS API needs to validate requests independently. Solved with signed JWTs that include workspace claims, validated by a NestJS guard. Socket.io reuses the same guard at connection time.
- 03
Avoiding 'too realtime'
Naive implementation pushed every keystroke through the socket — fine for 2 collaborators, awful for 10. Debounced collection edits to 250ms windows and batch-emit on the server. Cursor positions stayed throttled at 60ms because they're cheap.
Next
Want to talk through how it's built?
Happy to walk through the code, the deployment, or any of these decisions in more depth.