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

The netsh int ipv4 show dynamicport tcp command allows you to view the currently configured starting port and the total number of available dynamic ports specifically for the TCP protocol over IPv4.

Here are the key details regarding this topic:

Default Ranges: To comply with Internet Assigned Numbers Authority (IANA) recommendations, modern versions of Windows default to a dynamic port range that starts at 49152 and ends at 65535. This is a significant increase from older versions of Windows (like Windows Server 2003), which defaulted to a much smaller range of 1025 through 5000.

Separation by Transport and Protocol: The system maintains separate dynamic port range configurations for TCP and UDP, as well as for IPv4 and IPv6. You can view the others by changing the netsh command accordingly (e.g., netsh int ipv6 show dynamicport udp).

Modifying the Range: Administrators can adjust this range using a corresponding set command, such as netsh int ipv4 set dynamicport tcp start=10000 num=1000. When customizing these settings, the minimum starting port must be at least 1025, the range must include at least 255 ports, and the maximum ending port cannot exceed 65535.

Relevance to Troubleshooting: Knowing your dynamic port range is essential when diagnosing port exhaustion. If an application rapidly creates too many outbound connections, it can consume all the available ports in this dynamic range. Once the pool is exhausted, any new outbound connection attempts from your machine will completely fail until old ports are released back into the available pool