TradeForge

The problem

Most personal projects prove a single skill — a UI, an API, a clever script. I wanted something that forced the same architectural decisions a real trading platform team has to make: how to split a frontend into independently deployable pieces, how to share data-access logic across them without duplicating it, and how to keep a backend API honest about ownership of orders, positions, and market data as the surface area grows.

The solution

TradeForge is an Nx monorepo with 2 deployable apps and 20 internal libraries, including a shared data-access layer of 20 injectable services consumed by the shell and its feature micro-frontends. The frontend is split into Module Federation-loaded micro-frontends built from 38 Angular standalone components; the backend is a NestJS API with 11 REST controllers — auth, orders, positions, market-data, watchlist, analytics, and more — backed by 14 services and Prisma ORM, including its own migrations and seed scripts.

Architecture decisions

• Nx enforces library boundaries between feature, data-access, and UI layers, so a change to order-book logic can't silently leak into an unrelated feature module.
• Module Federation lets feature micro-frontends deploy independently of the host shell — the same constraint a multi-team trading platform has to design around.
• The NestJS layer mirrors the frontend's domain boundaries: auth, orders, positions, market-data, watchlist, and analytics each get their own controller and service instead of one catch-all API module.
• Prisma ORM with versioned migrations and seed scripts keeps the database schema and local development data reproducible across environments.

Trade-offs

• Module Federation and Nx project boundaries add real setup and tooling overhead — worth it here because the goal was practicing the architecture, not shipping the fastest possible UI.
• Running a full Nx + NestJS + Prisma stack for a personal project is heavier than a single app would be; that was a deliberate trade for full-stack ownership of every layer.

Impact

• Demonstrates the same architectural decisions used on production trading platforms — micro-frontend boundaries, shared data-access layers, domain-aligned API design — end to end in one self-contained system.
• Functions as a live reference codebase for the frontend-architecture and Nx/monorepo writing published on this site.

What I learned

• Nx's real value isn't build speed — it's that library boundaries make bad coupling visible at compile time instead of in a post-mortem.
• Designing the NestJS controllers around the same domain boundaries as the frontend features made both sides easier to reason about; mismatched boundaries on either side tend to surface as awkward API shapes.