Exploring Modern Web Architectures: Monoliths, Monorepos, Multirepos, and Microfrontends

Monolith vs Monorepo vs Multi-Repo vs Microfrontend
Gity Ghasemi (Front-End developer)

Monolith
When to
Use:
• Simplicity: For small to medium-sized projects with relatively simple architecture, a
monolith can be easier to develop and maintain.
• Initial Stages: In the early stages of a project where quick development and prototyping
are essential, a monolith can provide a straightforward solution.
• Tightly Coupled Features: When features are highly interdependent and there's no need
for independent scaling or deployment.

Monolith
Props and Cons
Pros :
Simplicity: Easier to develop and deploy initially.
Singular Codebase: Simple to maintain with a single codebase.
Cons :
Scalability: Challenges can arise when the application grows in complexity or requires
independent scaling of components.
Dependency Challenges: Adding new features might lead to bloating and increased
dependencies.

Monorepo
A monorepo, short for "monolithic
repository," refers to a version control
system where multiple projects or
components are stored within a single
repository. It's a way of organizing code
where various related projects or
services coexist in one place. These could
be different applications, libraries, or
services that share common
dependencies, code, and tooling.

Monorepo
Props
• Lowers Barriers of Entry
• Centrally Located Code Management
• Painless Application-Wide Refactorings
• More Difficult To Break Adjacent
Functionality
• Teams Share Development Culture
• easier Collaborate
• Version Control : single version history
• Code Reusability
Cons
• Slower Development Cycles
• Requires Download of Entire Codebase
• Unmodified Libraries May Be Newly Versioned
• Forking Is More Difficult

Monorepo
When new staff members start working for a company, they need to download the
code and install the required tools to begin working on their tasks. Suppose the project
is scattered across many repositories, each having its installation instructions and
tooling required. In that case, the initial setup will be complex, and more often than
not, the documentation will not be complete, requiring these new team members to
reach out to colleagues for help.
A monorepo simplifies matters. Since there is a single location containing all code and
documentation, you can streamline the initial setup.
Prons - Lowers Barriers of Entry

Monorepo
Having a single repository gives visibility of all the code to all developers. It simplifies
code management since we can use a single issue tracker to watch all issues
throughout the application’s life cycle.
For instance, these characteristics are valuable when an issue spans two (or more)
child libraries with the bug existing on the dependent library. With multiple
repositories, it may be challenging to find the piece of code where the problem
happens.
On top of this, we would need to figure out which repository to use to create the issue
and then invite and cross-tag members of other teams to help resolve the problem.
With a monorepo, though, both locating code problems and collaborating to
troubleshoot become simpler to achieve.
Prons - Centrally Located Code Management

Monorepo
When creating an application-wide refactoring of the code, multiple libraries will be
affected. If you’re hosting them via multiple repositories, managing all the different
pull requests to keep them synchronized with each other can prove to be a challenge.
A monorepo makes it easy to perform all modifications to all code for all libraries and
submit it under a single pull request.
Prons - Painless Application-Wide Refactorings

Monorepo
With the monorepo, we can set up all tests for all libraries to run whenever any single
library is modified. As a result, the likelihood of doing a change in some libraries has
minimized adverse effects on other libraries.
Prons - More Difficult To Break Adjacent Functionality

Monorepo
Even though not impossible, with a monorepo approach, it becomes challenging to
inspire unique subcultures among different teams. Since they’ll share the same
repository, they will most likely share the same programming and management
methodologies and use the same development tools.
Prons - Teams Share Development Culture

Monorepo
Monorepos make it easier for developers to collaborate and share knowledge, since all
code is stored in one central location. Multi repos, on the other hand, can make it
harder for developers to see what other teams are working on, since each team has its
own separate repository.
Prons - Collaboration

Monorepo
Monorepos provide a single version history for all code, which can make it easier to
track changes and roll back to previous versions. Multi repos, on the other hand, can
make it harder to manage version control, since each repository has its own separate
history.
Prons - Version Control

Monorepo
Monorepos make it easy to share code across different services and applications, since
all code is stored in one central location. Multi repos, on the other hand, require
developers to copy code from one repository to another, which can lead to duplication
and inconsistencies.
Prons - Code Reusability

Monorepo
When the code for a library contains breaking changes, which make the tests for
dependent libraries fail, the code must also be fixed before merging the changes.
If these libraries depend on other teams, who are busy working on some other task
and are not able (or willing) to adapt their code to avoid the breaking changes and
have the tests pass, the development of the new feature may stall.
What’s more, the project may well start advancing only at the speed of the slowest
team in the company. This outcome could frustrate the members of the fastest teams,
creating conditions for them to want to leave the company.
In addition, a library will need to run the tests for all other libraries too. The
more tests to run, the more time it takes to run them, slowing down how fast we can
iterate on our code.
Cons - Slower Development Cycles

Monorepo
When the monorepo contains all the code for a company, it can be huge, containing
gigabytes of data. To contribute to any library hosted within, anybody would require a
download of the whole repository.
Dealing with a vast codebase implies a poor use of space on our hard drives and
slower interactions with it. For instance, everyday actions such as executing git status
or searching in the codebase with a regex may take many seconds or even minutes
longer than they would with multiple repos.
Cons - Requires Download of Entire Codebase

Monorepo
When we tagthe monorepo, all code within is assigned the new tag. If this action
triggers a new release, then all libraries hosted in the repository will be newly released
with the version number from the tag, even though many of those libraries may not
have had any change.
Cons - Unmodified Libraries May Be Newly Versioned

Monorepo
Open source projects must make it as easy as possible for contributors to become
involved. With multiple repositories, contributors can head directly to the specific
repository for the project they want to contribute to. With a monorepo hosting various
projects, though, contributors must first navigate their way into the right project and
will need to understand how their contribution may affect all other projects.
Cons - Forking Is More Difficult

Multi-Repo
Props
• Independent Library Versioning
• Independent Service Releases
• Helps Define Access Control Across the
Organization
• Allows Teams To Work Autonomously
• easier to manage Complexity
Cons
• Libraries Must Constantly Be Resynced
• May Fragment Teams

Multi-Repo
When tagging a repository, its whole codebase is assigned the “new” tag. Since only
the code for a specific library is on the repository, the library can be tagged and
versioned independently of all other libraries hosted elsewhere.
Having an independent version for every library helps define the dependency tree for
the application, allowing us to configure what version of each library to use.
Prons - Independent Library Versioning

Multi-Repo
Since the repository only contains the code for some service and nothing else, it can
have its own deployment cycle, independently of any progress made on the
applications accessing it.
The service can use a fast release cycle such as continuous delivery (where new code is
deployed after it passes all the tests). Some libraries accessing the service may use a
slower release cycle, such as those that only produce a new release once a week.
Prons - Independent Service Releases

Multi-Repo
Only the team members involved with developing a library need to be added to the
corresponding repository and download its code. As a result, there’s an implicit access
control strategy for each layer in the application. Those involved with the library will be
granted editing rights, and everyone else may get no access to the repository. Or they
may be given reading but not editing rights.
Prons - Helps Define Access Control Across the Organization

Multi-Repo
Team members can design the library’s architecture and implement its code working in
isolation from all other teams. They can make decisions based on what the library does
in the general context without being affected by the specific requirements from some
external team or application.
Prons - Allows Teams To Work Autonomously

Multi-Repo
Monorepos can become more complex and difficult to manage as the codebase grows
in size and complexity. Multi repos, on the other hand, can make it easier to manage
code for separate services and applications, but can become more difficult to manage
as the number of repositories grows.
Prons - Complexity

Multi-Repo
When a new version of a library containing breaking changes is released, libraries
depending on this library will need to be adapted to start using the latest version. If
the release cycle of the library is faster than that of its dependent libraries, they could
quickly become out of sync with each other.
Teams will need to constantly catch up to use the latest releases from other teams.
Given that different teams have different priorities, this may sometimes prove arduous
to achieve.
Consequently, a team not able to catch up may end up sticking to the outdated version
of the depended-upon library. This outcome will have implications on the application
(in terms of security, speed, and other considerations), and the gap in development
across libraries may only get wider.
Cons - Libraries Must Constantly Be Resynced

Multi-Repo
When different teams don’t need to interact, they may work in their own silos. In the
long term, this could result in teams producing their subcultures within the company,
such as employing different methodologies of programming or management or
utilizing different sets of development tools.
If some team member eventually needs to work in a different team, they may suffer a
bit of culture shock and learn a new way of doing their job.
Cons - May Fragment Teams

W H O ’ S U S I N G M O N O R E P O V S M U L T I - R E P O
Monorepo
• Google,
• Facebook,
• Twitter,
Multi-repo
• Netflix
• Amazon
• Lyft

Microfrontend
When to Use:
Team Independence: When different teams or stakeholders need to work on different parts of the application
independently.
Large Teams: When multiple teams are working on different parts of the application.
Scalability: For projects expecting significant growth where independent deployment and scaling of features are essential.
Technology Diversity: When various parts of the application require different technologies or frameworks.
Small Projects: For small applications where the overhead of managing microfrontends outweighs the benefits.
Performance-Critical Applications: In scenarios where performance is a top priority due to increased requests and loading
times.
Tightly Coupled UI: If the application requires a highly cohesive and tightly integrated UI, microfrontends might add
unnecessary complexity.
When Not to Use Microfrontends:

Microfrontend
Props
• Lowers Barriers of Entry
• Centrally Located Code Management
• Painless Application-Wide Refactorings
• More Difficult To Break Adjacent
Functionality
• Teams Share Development Culture
• easier Collaborate
• Version Control : single version history
• Code Reusability
Cons
• Complexity
• Performance Overhead
• Versioning and Dependency Management
• Cross-Cutting Concerns

Microfrontend
If you want how we can resove UI consistency problem in microfrontend read this section
otherwise skip this section.
UI consistency in a microfrontend (chatgpt)
defining shared UI elements is possible in a microfrontend architecture. While microfrontends allow independent
development, they don't necessarily mean sacrificing consistency across the user interface. Here's how you can
achieve UI consistency in a microfrontend setup:
Design Systems:
Create a centralized design system or component library that houses shared UI elements like buttons, forms,
headers, and other interface components. This ensures consistency across microfrontends.
Shared UI Components:
Develop UI components that can be reused across different microfrontends. These components should adhere to
the guidelines set in the design system.

Microfrontend
Versioned Components:
Version control your shared UI components to manage updates and changes across multiple
microfrontends. This ensures that all microfrontends can upgrade to newer versions of shared
components when needed.
UI Contracts:
Define and document UI contracts or interfaces that specify how different microfrontends interact with
shared UI elements. This helps in maintaining consistency while allowing flexibility in development.
Style Guides and Best Practices:
Establish clear style guides and best practices for UI development across all microfrontends. Consistency
can be achieved by following these guidelines.
Cross-Microfrontend Collaboration:
Encourage collaboration and communication between teams working on different microfrontends to
ensure alignment with the shared UI standards.

Microfrontend
While microfrontends offer autonomy to teams, establishing mechanisms for
sharing UI elements ensures consistency without compromising the benefits of
independent development. However, it's important to note that ensuring complete
UI consistency across microfrontends might still pose challenges compared to a
monolithic approach, especially when dealing with complex interactions or layouts.

Microfrontend
There are some approach to implement microfrontend. You can see 11 way for
implement microfrontends in below link:
here we speak about single-spa and module federation.

Microfrontend
Building single-spa applications
A single-spa registered application is everything that a normal SPA is, except that it doesn't have
an HTML page. In a single-spa world, your SPA contains many registered applications, where
each has its own framework. Registered applications have their own client-side routing and their
own frameworks/libraries. They render their own HTML and have full freedom to do whatever
they want, whenever they are mounted. The concept of being mounted refers to whether a
registered application is putting content on the DOM or not.

Microfrontend
Splitting up applications in microfrontends (Monolith/Monorepo/MultiRepo)
Option 1: One code repo, one
build
The simplest approach for using single-spa is to have one code repository with everything in it. Typically, you
would have a single package.json with a single webpack config that produces a bundle that can be included in
an HTML file with a <script> tag.
Prons
• Simplest to set up
• monolithic version control has some
advantages
Cons
• One master Webpack config and package.json
means less flexibility and freedom for each individual
project
• Slow build times once your project gets large
• Builds and deployments are all tied together, which
can necessitate fixed release schedules instead of ad hoc
releases.

Microfrontend
Option 2: NPM packages
Create a root application that npm installs each of the single-spa applications. Each child application is in a
separate code repository and is responsible for publishing a new version everytime that it updates. The root
application should reinstall, rebuild, and redeploy whenever a single-spa application changes.
Typically, the single-spa applications compile themselves separately with babel and/or webpack.
Prons
• npm install is familiar and easy to set up
• Separate npm packages means each
application can build itself separately before
publishing to npm
Cons
• The root application must reinstall the child
applications in order to rebuild/redeploy
• Medium difficulty to set up

Microfrontend
Option 3:
Monorepos
Create a monorepo with multiple SPAs in a single (mono) repo. This allows for separate builds and deployment
without having separate code repositories.

Microfrontend
Option 4: Dynamic Module Loading
Create a root application which can allow single-spa applications to deploy themselves separately. To do so,
create a manifest file that the single-spa applications update during their deployment process, which
controls which versions of the single-spa applications are "live". Then change which JavaScript file is loaded
based on the manifest.
Changing which JavaScript file is loaded for each child application can be done in many ways.
• Web server: have your webserver create a dynamic script tag for the "live" version of each single-spa
application.
• Use a module loader such as SystemJS that can download and execute JavaScript code in the browser from
dynamic urls.

Microfrontend
Module Federation
With Module Federation, code can be split into smaller, independently deployable modules that can be loaded on demand
when they are needed. This allows micro-frontends to be developed and deployed independently, which reduces coordination
between teams and allows for faster development cycles.
At its core, Module Federation is based on the idea of remote loading of JavaScript modules. This means that instead of having
all the code for a single application loaded at once, the code can be split into smaller, independently deployable modules that
can be loaded on demand when they are needed.
Module Federation is implemented using the Webpack module bundler. Webpack is a tool that allows developers to bundle
JavaScript modules into a single file that can be loaded by a web browser. With Module Federation, Webpack is extended to
allow modules to be loaded from other applications, rather than just from within the same application.
To use Module Federation, developers need to configure their Webpack builds to expose certain modules to other applications
and to consume modules from other applications. This can be done using the exposes and remotes options in the Webpack
configuration.

Microfrontend
Module Federation vs single-spa
• The main difference between module federation and single-spa is the way they handle the sharing and reuse of
modules. Module federation uses a central “entry” point for each module, while single-spa uses a “shell”
application to load and manage different micro frontends.
• Another key difference is the flexibility of the architecture. Module federation requires that all modules be built
using the same framework, while single-spa allows for the use of different frameworks within the same
application.
• In terms of performance, module federation can be more efficient when sharing code across modules, while
single-spa can be more efficient when loading and managing micro frontends.
• Finally, when using module federation with Angular, React, or Vue JS frameworks, it is important to note that
each module must be built using the same framework, while single-spa allows for the use of different
frameworks within the same application.
https://blog.bitsrc.io/module-federation-vs-single-spa

C H O O S I N G B E T W E E N A P P R O A C H E S
In summary, the multi-repo approach can help create a culture of “move fast and break
things” among teams, where nimble independent teams can produce their output at
their speed. Instead, the monorepo approach favors a culture of awareness and care,
where teams should not be left behind to deal with a problem all by themselves.
Choosing between these approaches depends on various factors such as project size,
team structure, scalability requirements, and anticipated growth. A monolith might be
suitable for simpler projects, while microfrontends are ideal for larger, rapidly scaling
applications with diverse teams. Monorepos are effective for managing shared
codebases across multiple projects or microservices.

Team Structure: If multiple teams are working independently on different parts,
microfrontends could be advantageous.
Performance Requirements: Evaluate if the potential performance overhead of
microfrontends is acceptable.
Long-Term Maintenance: Assess whether the benefits in maintenance and scalability
outweigh the added complexity.
Assessing the specific needs and trade-offs of your project will help determine the most
appropriate architecture.

In a scenario where your current project is relatively simple but has the potential to scale and be divided
among multiple teams in the future, you can adopt an approach that allows for flexibility and scalability
without overcomplicating the initial development phase. Here are some steps you could consider:
1. Monolithic Approach Initially: Start with a monolithic architecture for the current simple project. This
approach allows for quick development without the complexities of microservices or microfrontends.
2. Modular Design: Even within a monolithic structure, design the codebase in a modular way. Use
components or modules that can be easily separated or extracted in the future without major
refactoring.
3. Service-Oriented Architecture (SOA): Design the application with a service-oriented mindset. Even in a
monolith, ensure that different functionalities are encapsulated as services, making it easier to later
extract these into microservices or microfrontends.
Chatgpt recommendation for implement project

4. API Contracts and Interfaces: Define clear APIs and interfaces between different parts of the
application. This allows for easier decoupling and future separation into microservices or
microfrontends.
5. Plan for Future Scaling: Keep scalability in mind while designing the system. Make sure the
architecture can accommodate future growth and team expansion.
6. Continuous Refactoring and Improvement: Regularly review and refactor the codebase to ensure it
remains flexible. This might involve breaking down larger modules into smaller ones or separating
concerns to prepare for future transitions.
7. Gradual Transition: As the project grows and the need for multiple teams arises, start considering the
transition towards a microservices or microfrontends architecture. This transition can be gradual, taking
one module or functionality at a time and converting it into a separate service or microfrontend.
Chatgpt recommendation for implement project

By taking these steps, you can strike a balance between
building a simple initial project while keeping the architecture
flexible enough to accommodate future scaling and division
among multiple teams without major disruptions or
overengineering at the outset. It's crucial to continuously
reassess the architecture as the project evolves to ensure it
aligns with the changing needs and growth trajectory.

Thank you!

Exploring Modern Web Architectures: Monoliths, Monorepos, Multirepos, and Microfrontends

More Related Content

Similar to Exploring Modern Web Architectures: Monoliths, Monorepos, Multirepos, and Microfrontends (20)

Recently uploaded (20)

Exploring Modern Web Architectures: Monoliths, Monorepos, Multirepos, and Microfrontends