Repo Architecture Tradeoffs

Full-stack teams must decide how frontend, backend, shared types, infrastructure, and tests live in source control. There is no universal answer. The right structure supports how the team ships.

Monorepo

A monorepo keeps related apps and packages together.

apps/
  web/
  api/
packages/
  contracts/
  ui/
  config/

Benefits include shared tooling, atomic changes, and easier type sharing. Costs include larger CI scope, dependency graph complexity, and the need for clear package boundaries.

Separate Repositories

Separate repositories can give teams independent release cycles and simpler ownership. Costs include contract drift, harder cross-stack changes, and duplicated tooling.

export type CreateTaskRequest = {
  title: string;
  projectId: string;
};

export type TaskResponse = {
  id: string;
  title: string;
  completedAt: string | null;
};

Shared contracts are useful, but they should not become a shortcut for skipping API compatibility.

Further Learning

Search these terms to go deeper:

• “monorepo vs polyrepo tradeoffs” — repository strategy comparison
• “shared TypeScript types frontend backend” — contract sharing patterns
• “contract testing APIs” — keeping separate services compatible
• “Turborepo package boundaries” — managing full-stack monorepos

Repo Architecture Tradeoffs

When your app has a frontend, a backend, and shared code, where does it all live? Two common answers: one big repository (a “monorepo”) or separate repositories for each piece. Neither is universally right — it depends on your team.

One repo, several apps (monorepo)

apps/
  web/
  api/
packages/
  contracts/   ← shared types both apps use
  ui/

Pros: you can share TypeScript types between frontend and backend directly, and change both sides in one commit. Cons: builds and tests can get slower as everything lives together, and you need clear boundaries so packages don’t become tangled.

Separate repos

Pros: each team/app can release on its own schedule, ownership is crystal clear. Cons: the frontend and backend can drift out of sync — the API changes, and the frontend doesn’t find out until something breaks.

// shared "contract" types — whether shared via monorepo package
// or copy-pasted between repos, keeping these in sync matters
export type TaskResponse = { id: string, title: string }

In one sentence

A monorepo makes sharing types and code easy but needs disciplined boundaries; separate repos give independent release cycles but risk contract drift between frontend and backend — pick based on how your team actually ships.

Want to go deeper?

Switch to Expert mode above for contract testing between services and tools like Turborepo.