Microservices architecture has gained significant traction due to its ability to break down monolithic applications into smaller, independently deployable services. However, the benefits have often been lop-sided. While backend developers have realized numerous advantages, frontend adoption has been held back by tight coupling, slow development cycles and scalability issues.
Microfrontends have emerged as a solution to these challenges by applying microservices principles to the frontend. And today we’re going to look at them in detail, providing a insightful article to understand what is a micro frontend architecture and how to take advantage of Module Federation for building your next web application.
This article is intended for front-end and full-stack developers who are interested in building large, scalable web applications using modern JavaScript frameworks.
Table of Contents
Ok, so, what are microfrontends?
Microfrontends enable us to divide a monolithic application into smaller apps, each of which is responsible for a singular feature. Instead of one big team working on everything, different teams can work on each of these small blocks independently to build the final frontend application.
Each block, or “micro app,” does a specific job within the overall application. These micro apps can be independently deployed and they are owned by independent teams, responsible for delivering business value in a focused area of the overall application. This means multiple teams can ship features independently.
The key focus is on self-deployment and team autonomy. If you or your team don’t have either of these, then you probably don’t need a microfrontend. A regular Single Page Application (SPA) may be more suitable and productive for you.
What the pros and cons of microfrontends?
Like any programming technology or concept, using a micro frontend approach have their advantages and disadvantages. Here’s a quick rundown.
Advantages
Accelerated development and deployment
Microfrontends turn an application into a series of independent units, which can be worked on and released without impacting the rest of the application. This approach significantly reduces overall development time and facilitates the faster delivery of new features to users.
Scalability for the long haul
Adding new features or functionalities simply involves creating additional microfrontends, each managed by a dedicated team. This granular approach eliminates the complexities associated with scaling monolithic applications.
Improved developer experience
Developers can work on their assigned microfrontends in isolation, without worrying about the codebases of other teams, which allows them to focus on their specific tasks more effectively. Additionally, microfrontends allow teams to choose the technology stack they prefer, which empowers developers to utilize the tools and frameworks they are most comfortable with.
Easier Isolated Testing
As each micro component of our app has an isolated and specific purpose, it’s a lot easier to test. Each component can tested in isolation so this isolation simplifies the testing process because developers only need to focus on their specific microfrontend.
Disadvantages
Increased complexity.
The independent codebases, and the interactions between them, make it more challenging to understand the overall system, maintain consistency, and manage dependencies.
Performance overhead.
Each microfrontend may need to fetch data from other microfrontends or backend services, which can introduce additional latency and degrade overall frontend application performance.
Coordination and communication challenges.
Ensuring alignment on design decisions, dependencies and release schedules requires effective communication and collaboration across teams, which can be particularly difficult for large organizations with distributed teams.
Testing and deployment complexity.
We have seen that the testing of each component is easier as it can be tested in an isolated environments, but this has a cost when doing integration testing as there’s a higher risk of integration issues when deploying multiple microfrontends together. So testing requires a very good planification and attention.
Understanding microfrontend patterns
Microfrontends are still in their early adoption phase. There isn’t a definitive right or wrong way to implement them; it heavily relies on the team.
At a very high level, there are two primary patterns for microfrontends: the Multi-SPA pattern and the Micro App pattern. These two patterns can be used regardless of whether you are developing a Server-Side-Rendered (SSR) or Client-Side-Rendered (CSR) application.
Multi-SPA pattern
In this scenario, the application consists of multiple micro frontends with independent single-page applications (SPAs), each web component deployed under its unique URL. When users navigate between these SPAs, the entire page reloads in the browser. This occurs because HTML href tags typically handle the navigation.
For example, the login app will deploy to a URL such as yoursite.com/login. When users navigate to this URL, the login SPA will load in the browser. Any subsequent navigation within the login app will also take place within the /login/ URL, such as /login/myaccount.
Micro App pattern
In this scenario, the web page is composed of various different web components. Each component is an independent micro app that can exist in isolation and work in tandem with other micro apps as part of the same page
The micro apps pattern is a lot more complex than the multi-SPA pattern and it is recommended mainly for very large web applications, where multiple teams own different elements on a single page. In this pattern, all the routes, both primary and secondary, are managed by the app shell.
Some misconceptions about microfrontends
The concept of “micro” in microfrontends is frequently misunderstood, with some assuming that an application adheres to a microfrontend architecture only when broken down to its smallest components. This misconception often prompts the unnecessary fragmentation of applications into excessively small units, introducing unwarranted complexity that undermines the intended benefits of microfrontends. Personally, I advocate a different approach. When breaking down an application into micro apps, teams should prioritize identifying the most substantial micro app or micro apps that a scrum team can independently manage and deploy to production, without causing disruptions to other micro apps.
Integrating Microfrontends
When building microfrontends, we need a container (host) app which will decide where and when to show each microfrontend. This implies that the container requires access to all sub-microfrontends at some point. The term used for this process is Integration.
In general, there are three major methods of integration.
Build-time integration
This is also known as compile-time integration. It means that during the build process, the host (container) application will download and integrate (load) all microfrontend apps. Hence, before loading the container in the browser, it will already have received access to the source code of all MFEs.
Run-time integration
This is also called client-side integration. In this case, the host (container) gets access to the micro frontends after it has been loaded onto the browser. These methods solve many challenges that come with the build-time integration, and we will focus on these challenges in our project below.
Server integration
With this method, a server decides whether or not to show the MFEs.
Introducing Webpack’s module federation
Webpack Module Federation is a Webpack plugin co-created by Zack Jackson. Introduced in Webpack 5, it enables the dynamic sharing of code between JavaScript bundles or microfrontends. This is a powerful tool that allows different applications to work together seamlessly by sharing modules or code, without the need for a full integration.
This feature is particularly useful in a microfrontend architecture, where multiple smaller frontend applications are composed to form a larger, cohesive application. Module federation allows these microfrontends to share modules and dependencies, facilitating better code organization, reducing duplication, and enabling more flexible and scalable development.
Alternatives to module federation
There are several other frameworks that can be used when working with Microfrontends.
- Fronts
- Bit
- [Ragu](https://ragu-framework.github.io/#!)
- iframes
- Single Spa
- Qiankun
- Piral
- puzzle-js
Common Pitfalls to Avoid when Building Microfrontends
Avoid packing your micro apps into NPM packages
It is often a practice to see teams package and version their micro apps into NPM packages before importing them into the Host app. This should be strongly discouraged because with any new update to the npm package all the hosts using that micro app will need to update their package.json files and rebuild and redeploy their apps, defeating the primary principle of independent deployments.
The excessive use of shared libraries can create “dependency hell” or a “distributed monolith”. This negatively impacts microfrontends since the utilisation of shared libraries or code undermines team autonomy. It creates interdependence among multiple teams, as they rely on updates or fixes within the shared library to progress with their work.
As a rule of thumb, do not make business or application logic a shared code among different micro apps but it’s okay to share the UI component library since it helps ensure that all micro apps have a consistent look and feel.
Don’t make your micro apps too small
Many developers mistakenly believe that microfrontend architecture requires extremely small micro apps. However, this is not the case. Creating overly small micro apps can increase complexity and maintenance challenges without delivering any benefits.
To determine the appropriate size for your micro app, consider the following factors:
- Is it the largest possible micro app that can function independently?
- Is it the largest possible micro app owned by a single agile scrum team?
- Does this app experience changes and updates at a different pace compared to the rest of the application?
If your response is “yes” to all these questions, then your micro app is the correct size. If any of the answers is “no” it may indicate that either the micro apps need to be restructured, or microfrontends may not be the suitable architectural choice.
Avoiding build-time compilation when assembling Microfrontends
Build-time compilation is typically beneficial as it lessens the browser and JavaScript engine load during runtime. However, this approach doesn’t assist in assembling the microfrontend. Whenever a microfrontend changes, you must rebuild the assembly layer, which contradicts the idea of independent micro app deployments.
Conclusion
In this article, we learned about architecting a microfrontend application. As we have seen Microfrontends offer a fresh approach to building scalable and efficient web applications. They balance speed of development with complexity and can be a useful approach when building your next project.
We recommend you to explore Micro Frontend development as it’s the new kid on the block in the web development community. This innovative approach allows development teams to break down their monolithic frontend. They split it into smaller, more manageable parts called micro frontends. By doing so, you can achieve greater flexibility, scalability, and maintainability in your web applications.
This technology offers the opportunity to develop small frontends independently. It can also leverage reusable components and enable incremental development and deployment. These features create new opportunities for building web applications that can scale, flex, and stay updated. So, embrace the micro frontend revolution and take your web development to the next level.
If you want to see a real example on how to build a Microfrontend application using React, check out our article where we explore how to create an e-commerce store with React and the Microfrontends architecture.
Happy Building!
