All You Need to Know About Micro FrontendsApril 14, 2022 • Andriy Obrizan • 13 min read
Micro-frontend architecture is a modern approach to front end development where a web app is split into self-contained components. These components are built separately but assembled together to appear as a single product to end-users. The logic behind micro frontends is similar to the concept of microservices with the exception that micro frontends relate to the client side of web solutions, not the server side.
Following a micro frontend approach makes the most sense when it comes to creating complex web-based products. Unlike a more traditional front-end monolith, micro frontends allow multiple teams to work independently on different pieces of software. With this architectural style, programmers can develop web apps faster, achieving a higher level of scalability and maintainability.
Table of Contents
Micro frontends represent a relatively new pattern in web development. In short, this approach aims to extend the benefits of microservices to the client side and eliminate the pitfalls associated with bulky front-end monoliths.
But what are those benefits, and why isn’t the monolith approach the best option for modern large-scale web development? Let’s explore.
Microservice architecture is an architecture type in back-end development. Unlike a monolithic architecture that is based on a single codebase, microservices comprise several independently deployable modules. These modules are organized around different business domains and are loosely connected with each other — usually via APIs. For this reason, they have minimum dependencies.
Most modern web solutions are based on microservices. Businesses often opt for this architecture type when building new web apps or shift from monolithic back end to microservices when modernizing their legacy software. Why? Microservice architecture is advantageous for both the development process and the product a team creates. Here are the main benefits:
- Scalability. With microservice architecture, scaling a web solution becomes easier. A development team can just scale one or several services that need more resources while leaving the rest of them untouched.
- Flexibility. There is no code sharing in web systems based on microservices. Programmers can modify separate services, and these changes won’t affect other modules of an application.
- Resilience. The microservice architecture ensures a higher level of resilience and reliability. Services are independent, so if one of them crashes, others keep functioning.
- No technology lock-in. Programmers can use different technologies for different services within one web solution.
- Faster development. Developers can work on multiple services in parallel. Plus, services are reusable. This naturally reduces the development time needed.
Basically, microservices are a good choice for most large-scale web development projects.
So, suppose a company has decided to build a web solution based on a microservice architecture. What’s wrong with combining it with a monolith front end? We’ll talk about this next.
As the name suggests, a front-end monolith is the client side of a web application built as a single codebase. A lot of solutions, including those based on a microservice architecture, still have this type of interface architecture. So, it’s quite common that the back end of a system is modular while the front end remains solid.
At first, this can work well, but issues often arise as a web solution grows. Here are just some of them:
- A front-end monolith becomes overloaded and inefficient as software evolves. As a result, the system slows down, and its performance degrades.
- A large and heavy front end creates a development bottleneck when a system is scaling. While services at the back end can be modified quickly, pushing updates at the client side may require major production and much time.
- Maintaining a large-scale web solution with a monolithic front end becomes a challenge. Independent deployments are not possible, so if one part goes down, the entire system may fail.
Summing up, a front-end monolith can diminish the advantages enabled by a microservice architecture. To avoid this, more and more developers are tending to use micro frontends. So, let’s dive deeper into how everything works when a micro-frontend architecture sits on top of microservices in a web solution.
When building web solutions based on micro-frontend architecture, developers decompose large interfaces into smaller fragments to deliver them independently. It means that each fragment is coded, tested, and deployed separately. Meanwhile, the solution interface appears to end-users as a single cohesive whole.
Paired with microservices, micro frontends allow developers to split an entire web solution into several end-to-end verticals. Simply put, a vertical comprises back-end and front-end parts of one system’s component (or feature). It means that each component is independent, so it can be fully developed (i.e., from a database to a user interface) by an autonomous cross-functional team.
Like any other style or method in web development, a micro-frontend architecture has its advantages and drawbacks. Let’s discuss this in more detail.
As mentioned, micro frontends are basically an extension of microservices to the client side of a web solution. So the benefits and drawbacks of these approaches are similar.
Using a micro-frontend architecture allows programmers to avoid the limitations of heavy monoliths. Let’s take a closer look.
When following a micro frontend approach, every component of a web app or site can be developed by an autonomous team. Each team is fully independent, which means that it’s responsible for an entire cycle of component creation, from ideation to release and to post-production. It also means that multiple teams can work in parallel on the same project, with no communication overhead. So, release cycles are much faster than with front-end monoliths.
It’s almost never possible to split a web solution into entirely isolated parts. So, micro frontends do communicate with each other. But the components are coupled loosely, and every coupling is meaningful. This ensures the advanced stability of a web solution: the failure of one component has minimal or no impact on the operation of all the other components.
Monolithic front ends have cumbersome codebases that become even more unstructured and difficult to maintain over time. Micro frontends solve this issue. The source code of each individual micro frontend is smaller, simpler, and, thus, much more manageable. This results in cleaner code throughout the entire web solution.
Independent deployments mean that each micro frontend is deployed separately from other components of a web solution. In other words, programmers can get features they’re working on all the way to production, giving just a little thought to what is happening with the rest of an app. So, basically, each feature has its own delivery pipeline and, thus, it can be rolled out relatively fast. There is no heavy monolith that needs to be adjusted to the modifications, so nothing holds back the deployment of individual features.
This advantage stems from the very nature of micro frontends. If a web solution is based on this architectural style, its client side is modular, and each module is independent. So, a team can test the part of the user interface they’re building or modifying alone, which is simpler than testing a large monolith.
Making major changes to a front-end monolith is always risky: one wrong move and all the features can go down. That’s why it’s not easy to make a decision about considerable modifications unless they’re absolutely necessary. With micro frontends, the situation is the opposite. Even major modifications in one component will not cause the failure of an entire system. So the idea of changes, regardless of their scale, won’t stress you out.
A micro-frontend architecture allows developers to use multiple front-end frameworks within a single web solution. Since components are independent, each of them can be built with different technologies that best suit the team’s tasks. Of course, programmers should be cautious when choosing frameworks for the piece of software they’re responsible for, and discussions with other teams are still highly advisable. But there is no risk that you’ll be stuck with a legacy framework for the entire app lifecycle.
As you can see, micro frontends are beneficial for web development projects in many ways. But this architectural style has its downsides, too. Let’s cover them briefly.
When a web solution is based on a micro-frontend architecture, testing its individual modules is simple. But it’s not the same as testing a web app as a whole. You’ll need to validate that all components work together as intended. Given that micro frontends are independent and have their own delivery pipelines, this might be challenging.
A micro-frontend architecture can also cause some complexities in the development and deployment processes. For example, autonomous development teams working on the same project can clutter a solution with too many components, which may lead to some issues at the deployment phase. Also, it’s not always easy to assemble all the modules correctly and make them fit seamlessly into the bigger picture — this task usually requires a good knowledge of all the dependencies.
Micro frontends allow development teams to use different technologies within a single project, which helps to avoid technology lock-in. But this advantage also has a flip side. When front-end frameworks for different modules aren’t chosen thoughtfully, you risk ending up with an inconsistent tech stack. This can result in a bunch of issues, from slow performance to an unpleasant user experience.
When teams work independently on different pieces of software, it’s difficult to keep the user interface cohesive. All the developers engaged in the project should have a common vision of the web solution. Otherwise, numerous inconsistencies may occur along the way.
Micro frontend projects usually require significant investments. Gathering and maintaining multiple front-end teams is costly. Plus, you’ll need management staff to plan the work, coordinate everything, and ensure effective communication between teams.
Despite all the advantages of a micro-frontend architecture, it’s not a one-fits-all solution. Not every project can benefit from using this architectural style. So, how do you know if micro frontends are a good option for your web app?
First, let’s summarize the key characteristics of the two main approaches to front-end development: a front-end monolith and micro frontends.
|Front-end monolith||Micro frontends|
|Codebase||Large and bulky||Split into small manageable modules|
|Deployment||Common cycle for the whole system||Independent cycles for each module|
|Feature development speed||Standard; may slow down over time||Fast (features may be released independently by autonomous teams)|
|Maintenance||Hard to maintain||Relatively easy to maintain|
|Stability||Insufficient (a glitch may break down the entire system)||High (a glitch in one component has a little or no impact on the system)|
|Updates||Lengthy (may require significant code rewrite)||Can be pushed quickly|
|Tech stack||Single stack for the entire system||May be different in the various modules|
|Testing||Lengthy and difficult (even a small change requires testing of the entire application)||Quick and easy — for individual frontends Difficult — for the web system as a whole|
|Team||A single team working on the project||Multiple teams working on the project|
|Budget||Depends on the project size and complexity||Always requires significant investments|
Now that you can see the big picture, let’s discuss the main criteria that should help you make the right choice. Here are some examples of when using micro frontends is a wise decision:
- Your web solution is complex, based on microservices, and can be split into multiple self-contained verticals. For example, you’re building an enterprise resource planning system consisting of several modules (e.g., finances, CRM, HR, inventory).
- You want to have different tech stacks for different modules within one web solution.
- You already have or are going to engage a big development team (or multiple teams), and your budget allows this.
So everything depends on the specifics of your business case. If you have doubts about whether micro frontends are a good fit for your project or not, we recommend consulting with a reliable tech partner like LeanyLabs.
Being a modern architectural style, micro frontends can bring a lot of benefits to large-scale web development projects that are based on microservices. It allows programmers to split the entire solution into independent components that can be built by multiple autonomous teams. This results in a number of advantages, including faster feature roll-out, simplified testing of individual modules, and smoother updates.
However, micro frontends also come with some challenges. For example, testing an application as a whole might be complicated. Also, micro frontend projects are quite costly since they require a big team of developers and managers. So, you have to consider all aspects of your business case before making a final decision.
Not sure if you can choose an architectural style yourself? LeanyLabs has expertise in both approaches — front-end monolith and micro frontends. Get in touch, and we’ll discuss your request in detail!