Micro-Frontend has been taking a lot of popularity these days, especially after the introduction of the Module Federation plugin with the Webpack5. It is pretty popular with E-Commerce sites too. In this article, we will figure out when to use Micro-Frontend, what are the challenges related to it, what are options available for it, and when not to use it. So, there is much learning in this short crisp point-to-point article.

Who are the audiences for this Article:

1. Who wants to stay updated about the ongoing popular tech?
2. Who wants to switch from Monolith-Frontend to Micro-Frontend?
3. Who wants to know about Micro-Frontend to use in the future?
4. Who wants to impress your future employer?
5. Who wants to understand Micro-Frontend from a 360 perspective?
6. Who is looking ahead to give an interview for a large-scale product-based organization?
7. Who is scared of using Micro-Frontend and wants to know its cons?

What is Micro-Frontend?

"An architectural design wherein a collection of individually deliverable frontend applications is combined to form a larger whole."

The philosophy behind Micro-Frontends is to think of the web application as a collection of features that are owned by different independent teams. By Micro-Frontend, a frontend project can be divided into separate micro-projects (and with separate teams) on the basis of functionalities, then these micro-projects can run and get deployed individually as well as together in a container without having any integration issues. Side note: Container (Parent) is used to run all child projects (Micro-Frontends) in integration.

So how is a Micro-Frontend architecture application different from the Monolith-Frontend application, what are the core requirements to be fulfilled by a Micro-Frontend? Let's see those points below.

Strict Requirements of an Application based on Micro-Frontend:

1. Every child project should be able to run individually and in combination without any excuse.
2. Zero coupling between child projects, some data can only be passed by callbacks or custom events.
3. Near-zero coupling between container and child apps.
4. We can show two or more Micro-Frontends at the same time on the same page.
5. Both container and sub-apps can have routing features and can keep adding routes dynamically.
6. We can use off-the-shelf routing solutions without much custom work.
7. The navigation feature should work fine in both isolations and hosted(combined) mode.
8. If different sub-apps need to communicate about routing, it should be done in as generic a fashion as possible.
9. Version control (Monorepo vs separate) shouldn't have any impact on the overall project.
10. Last but not least, CSS from one project shouldn't affect another.

These could be other requirements of this architecture based on the project but these are major inflexible requirements that provide a base for any micro-frontend based project that should be developed.

Now let us discuss the major benefits of using a Micro-Frontend.

Benefits of Micro-Frontend Architecture:

1. Smaller, more cohesive, and maintainable codebases.
2. More scalable organizations with decoupled codebases, and autonomous teams.
3. Ability to upgrade, update, or even rewrite parts of the frontend in a more incremental fashion that wasn't previously possible.
4. Independent deployment, No dependency, any sub-app can go to production alone.
5. Allow to use of new technology (like Vue, Svelte, etc) independently in any sub-app.
6. Save from regression testing.
7. You can fix the module which is having issues while the rest of the apps keep working.
8. Heterogeneous technology usage i.e., having space to use multiple technologies in a large project with smooth integration. Allow different tech stacks to co-exist in the same project.
9. Ensures each application only has an implementation of the code for its specific business functionality, with no conflicts.
10. You can roll back a bad release without affecting the work of other teams, save from many git issues.

By the above points, hope you have got an idea about when to use Micro-Frontend in your project or organization.

Now let us discuss the major challenges (or cons) of Micro-Frontend before you start using it in your project.

Cons (or challenges) in Micro-Frontend Architecture:

1. Loading time: Some micro frontend implementations can lead to duplication of dependencies, increasing the number of bytes that end users must download.
2. Duplicate code: By splitting an application, you reduce the ability to discover existing code.
3. Managing the global state, you have to rely on the event bus type mechanism.
4. Inter-app communication can't be done freely and have to be very limited.
5. UI/UX inconsistency could be there if a common design system isn't used and common UI components aren't shared across all micro-frontend apps using a private npm repo (or something).
6. The more technology stacks and applications included, the slower it may be on the user's browser. Because the browser has to fetch data of different UI libraries or frameworks used (like React, Angular, and Vue all together on a page).
7. More complex development process, therefore developers should have a good working understanding of the architecture.
8. The shared libraries become another avenue for bugs to sneak in (need to be managed carefully).
9. Micro-Frontends could cause issues in production that couldn't be discovered in development (Test Wisely in initial phases).
10. A repository is needed to serve common content among micro frontends like utility functions, web components, etc.

Therefore, hope you have got an idea about when not to use Micro-Frontend in your project or organization. If you feel that you won't be able to cope with the above points then please rethink before diving into the Micro-Frontends world.

Let's also look for the popular options available for using Micro-Frontend architecture in your projects.

Available Popular Options:

• Module Federation (Prefered)
• Single-SPA
• Bit

Hope you have got an answer to your questions regarding Micro-Frontends in this point-to-point article. It is good to get specialized in the frontend knowledge so please follow and stay tuned for that. Please like and comment, it motivates me to keep creating such stuff. Discord Channel: Senior Frontend Dev - only senior frontend engineers allowed.