Frontend System Design

The two-part series on scaling web applications provides a complete framework for handling frontend growth, covering both architectural design (how the application itself is structured) and code organization (how the repositories are managed).While Part 1 established that applications typically evolve from a Monolithic Architecture to a Modular Monolith, and ultimately to Micro-frontends as teams and complexity grow, Part 2 details how to actually store and manage the code for these complex systems.Code Organization: Monorepos vs. Polyrepos Once an application is split into multiple modules or micro-frontends, you must decide how to store them.Monorepositories: A single repository that contains multiple projects or applications.The Benefits: They provide high visibility across the entire codebase, making it much easier to trace bugs across different modules. They also drastically simplify code sharing (like shared UI libraries) and allow for standardization of linting and naming conventions across all teams.The Drawbacks: They are prone to merge conflicts, can create "fragile modules" (where updating shared code breaks multiple applications simultaneously), and make it nearly impossible to restrict security access to specific teams.Polyrepositories (Multiple Repositories): Separate repositories for each individual project or component. These are generally the best choice for highly independent micro-frontends, as they offer teams maximum autonomy and prevent deployment bottlenecks.The Full-Stack Monorepo Strategy For small to medium-sized cross-functional teams, housing both the frontend and backend applications in a single monorepo is a highly effective strategy. If both the frontend and backend use TypeScript, you can leverage tools like tRPC (TypeScript RPC). This allows the frontend to call backend functions directly without worrying about HTTP verbs or REST URLs, seamlessly blending the development experience.Managing Versions in a Monorepo When housing multiple projects together, versioning becomes a challenge. Teams typically use one of three approaches:Semantic Release: Fully automated versioning and package publishing.Manual Versioning: Developers or maintainers manually decide the next version number.Global Versioning: All projects share the exact same version number. While simple, a change in one single package requires bumping the version for the entire repository, which becomes computationally expensive for massive projects.The Decision Framework The series concludes by emphasizing that there is no single "perfect" scaling strategy; choices should be dictated strictly by project and team size.For a small application (like a simple to-do list) maintained by 2-3 developers, a Monolith in a Monorepo is the best choice. It allows for consistent UI, easy debugging, and rapid early-stage development. Over-engineering this with micro-frontends would waste valuable time and resources.For a massive enterprise application (like a complex admin dashboard with separate domains for users, budgets, and metrics) managed by multiple independent teams, adopting Micro-frontends in Polyrepositories is ideal. This ensures each team can develop, test, and deploy their services without stepping on each other's toes