Article
Micro Frontend Architecture: What, Why, and How to Use It
Author
Andrii Shpak
Published
November 14, 2023
Time
10 mins to read
Table of Contents
Micro frontend architecture is the latest trend in web application development that offers a flexible and scalable approach to building web applications.
Micro frontends have grown in popularity as a solution for many businesses due to the rise of complex web applications and the demand for quicker releases. This article will discuss what micro frontends are, their advantages and disadvantages, and when to use them.
What are micro frontends?
Micro frontends is an architectural style of frontend web development where an application is split into features – micro frontends – and delivered independently. This is done to improve the delivery quality and efficiency of teams responsible for frontend code.
Each microfrontend can have its own source code repository, set of dependencies, automated test suite, and delivery pipeline. Each of them is most likely owned by a single frontend team and is developed, tested, and deployed independently from other features, increasing the efficiency of the development process.
The term “micro frontends” has been introduced relatively recently – in 2016 it was used by Michael Geers, and at the end of the same year, it appeared in ThoughtWorks Technology Radar. However, frontend developers have used this architectural approach for quite some time to benefit from modularity, independent deployment, and scalability in frontend development.
What is the difference between microservices and micro frontend?
A microfrontend is basically a microservices counterpart in the frontend world.
Microservices is a popular approach to the backend architecture where the backend monolith is split into different loosely coupled components (services). Micro frontend uses the same concept as microservices and breaks down a web application into smaller independent modules that can be developed autonomously but together form one whole.
Those separate components (micro frontends) can have different repositories, areas of responsibility, and pipelines, but assigning each separate component to an individual independent team is not necessary. In the end, all modules are put together to present a website that provides a seamless and personalized experience for its users.
This is actually the most important part and a challenge of microservices – to connect all modules together so the result looks and works as one website.
What is a good example of micro frontends?
At first, all web applications were built as a monolith because it was simpler and easier to manage. All the code, business logic, and data access layers were tightly coupled and deployed as a single unit. Developers had only one repository, one build, one pipeline, and one infrastructure, making development and testing more straightforward.
However, as web apps grew in complexity, monolithic architecture became less practical. With huge websites such as Amazon, PayPal, Ryanair, and Netflix, where multiple development teams work on different functionalities, it becomes harder to make changes or add new features without affecting the entire system and maintaining high quality. Such challenges as scalability and fault tolerance arise as well because scaling up requires scaling the entire application, which could be expensive and inefficient.
This led to the introduction of microservices and micro frontends, which offer a more modular and flexible approach to developing web applications. The website’s monolithic architecture is broken down into smaller, more manageable services, which enables developers to scale and deploy components independently.
App’s frontend is divided into different sections, each developed and deployed independently as a micro frontend, making the entire system more resilient and easier to maintain.
Take a look at Netflix, as an example.
Their website is built on microservices architecture and frontend is divided into different sections, each powered by a separate micro frontend. In that way, a home page, search functionality, user profile settings, etc. can be cached independently and only updated when necessary, reducing the overall load time for the user.
The Netflix frontend team adopted the micro frontend approach to encourage rapid development. This enables Netflix to release new features and updates quickly, without impacting the rest of the website.
How micro frontend works: integration approaches
Let’s start by taking a look at monolith architecture. It got its name from a solid block of stone that is one entity. In software development, a monolithic architecture refers to an application that is probably managed by one team with databases, backend, and frontend shared.
As applications have grown more complex, developers have seen the benefits of separating backend and frontend development. Then they applied the microservices approach to the backend to make the application more scalable, resulting in loosely coupled services that can be independently deployed.
The next logical step was to apply the same approach to the frontend, as the monolithic frontend became a bottleneck for rapid development. Making changes to the monolithic frontend affected the entire application, increasing the compilation time.
Additionally, problems with owning responsibility arise if multiple teams work on an app with a monolithic architecture. For example, two teams release multiple significant features to production, but after the release, performance stats go down by 30%. Both teams claim their code is perfect, so who is responsible for the decrease in performance stats? If everyone is responsible, then no one is responsible.
That’s why creating a micro frontend architecture makes sense. An application is split into isolated, self-managed, and independent parts, which are then glued together to look like one website.
Core ideas of micro frontend
We formed a list of central ideas behind micro frontend:
- Segmented parts, thicker domain boundaries – each feature lives within a separate micro frontend
- Autonomous teams – no need to coordinate releases with other development teams
- Loosely coupled app – all components can be independently built, deployed, scaled and even failed independently
- Shell – glues micro frontends together into something cohesive on a single page
Micro frontend integration approaches
Different micro frontend integration approaches are best described as a slider. On one side of the slider, the application is less separate and thus has fewer micro frontend benefits. In its defense, these approaches have a much easier setup – they require one micro frontend framework version and one library version. Suppose you move the slider to another side with more separation. In that case, the application ends up with bigger setup complexity and maintenance costs, but all micro frontend benefits can fully shine.
Let’s look at some of the most common micro frontend approaches.
Routing: loading separate applications
The idea behind this approach is that the application is separated based on routing and each route loads a completely independent application, including framework bundles inside. In this case, infrastructure works as a shell, and redirects between applications happen through e.g., API gateway or CDN.
Routing works for the page-level integration when different teams own the application’s pages, and each micro frontend is considered a single-page app.
Routing can be achieved with HTML links. In such a case, the page reloads on each page. There is no possibility for data sharing with this approach, only query parameters, session storage, or persisting data in the database.
Let’s see how it works from a user’s perspective. When a user navigates to a specific URL in the application, the central routing application receives the request. It determines which micro frontend should handle the request based on the URL. The selected micro frontend is loaded and displayed to the user, while the other micro frontends remain hidden.
If it is required for a page to be rendered without reloading, a shared application shell or a meta-framework like single-spa can be applied. The app shell consists of minimal HTML, CSS, and JavaScript. The user sees a static rendered page instantly even if the requested data is still pending from the server.
All interactions and updates are loaded without fetching them from the server, so the page is not refreshed upon each user’s request.
NPM packages approach
Each micro frontend is released as an individual package with the node package manager (NPM) approach. The shell application then lists these packages and incorporates them into the overall application. This approach offers the advantage of a fairly simple setup. However, it comes with certain drawbacks, such as the requirement for single-dependency versions and the inability to release a micro frontend without a shell release, which may create cross-team dependencies and hinder updates.
Iframe-based micro frontend
The iframe approach embeds each micro frontend in its own iframe, and a single page application (SPA) acts as the container. It is basically an HTML document put inside another HTML document. SPA is coordinating communication between iframes.
Iframes is a relatively old approach to building a micro frontend architecture. Even though it provides a good level of separation, many problems need to be solved for it to work (e.g., security, data sharing).
WebComponents
Web components imply building each micro frontend as an isolated component that can be deployed independently as a .js file. The application loads and renders them in the placeholders specially created in the layout. Web components tell the browser when and where to create a component.
The drawback of this approach is that each web component is large and needs to bundle its framework version. So even though you can separate as many components as you want, performance must be tracked carefully.
Module Federation
Module Federation is another approach that helps make all micro frontend components look like one application. On the slider of different levels of separation used in micro frontends, module federation can be placed somewhere in the middle. Module federation was released with Webpack 5 (2020), so it is modern and can be adopted by different frameworks.
Module Federation allows loading micro frontends at runtime into a shell application without any build time dependency (only integration ‘contracts’ need to be defined). This is especially useful when customizing your pages for specific clients. Your website may have a ‘checkout’ module loaded from a ‘common’ pack for most clients and a ‘customized’ one (maybe even built by the client’s development team) for others. Module federation allows you to change your micro frontends configuration in runtime.
Micro frontends benefits
Splitting the monolith into loosely coupled modules is a complicated task and only makes sense when micro frontends will solve the problems they are supposed to solve. If you don’t have these problems, there is little sense in going through the hassle of applying the micro frontend approach.
Here are the benefits the micro frontend approach can bring:
Faster deployment and better release management
In contrast to a monolithic frontend, where a single team is responsible for implementing all new functionalities and features, micro frontends enable smaller, autonomous teams to work simultaneously on deploying various functions and features. This considerably reduces the development time and accelerates the releases.
Multiple teams with different responsibilities
Each team is responsible for its micro frontend, which is self-contained. They can build, test, deploy, and update it independently. With monolith architecture, if Team A is ready for a release, and Team B needs time to prepare for it, Team A has to wait. This obstacle is removed in the micro frontend approach, as each team has the freedom to do what they choose, and without dependency on others.
Technology freedom
Each micro frontend might be implemented on different technology stacks because they are autonomous pieces of software. So teams working on them are free to choose their own technology stack, based on their expertise and experience.
Easy scaling
Micro frontends present yet another advantage to developers. Because each feature can be scaled independently, the entire process becomes more cost- and time-effective than with monoliths.
Continuous deployment
By breaking the monolithic frontend into smaller, independent components, micro frontends enable incremental updates without affecting the entire application. They also make it easier to roll back a single component to the previous version, can improve team collaboration by reducing bottlenecks, and increase scalability, among other advantages.
When should you use micro frontends?
Your project size is medium to large
Adopting a micro frontend approach is ideal when dealing with multiple teams working on distinct features. This architectural style offers better scalability and enables faster feature rollouts, without the risk of affecting the entire website.
Productivity is your priority
Independent teams working separately on micro frontends can enhance overall productivity. With teams working on different features simultaneously, without impacting each other’s processes, app development can be completed in a more organized and efficient manner.
Micro frontends benefits for different roles
Micro frontend architecture provides various benefits to different roles in an organization, not just software developers and testing engineers. Here are the benefits for marketing managers, CFOs, CTOs, and product managers.
Micro frontend benefits for Finance Directors
Faster releases = reduced costs
Micro frontends are developed autonomously, which results in more efficient development and faster releases. Developers work with a smaller amount of code within a micro frontend compared to monolithic applications. Because such code is much easier to manage, developers are less prone to making mistakes and work faster. This reduces costs for development and maintenance and gives better control over the budget for CFOs.
Better ROI
Having autonomous teams per micro frontend significantly speeds up the development process and shortens the release cycles. Faster deployment and releases enable faster time-to-market and reduce costs. Thus micro frontend architecture can provide a better return on investment (ROI), resulting in better financial outcomes for the organization.
Micro frontend benefits for Marketing Managers
Improved customer experience
Reduced coupling between pages gives more flexibility for marketing managers to try new things that can improve customer experience. On micro frontend architecture, CMOs can launch new features and campaigns faster and easily conduct A/B testing to determine which option works better.
Increased conversion rates
Conversion rates are one of the most critical pain points of marketing managers. Micro frontends can also improve that by providing a more personalized and seamless user experience. The marketing department can more freely and easily implement targeted content and messaging on separate pages or features, increasing engagement and conversion rates.
Micro frontend benefits for Product Owners
Improved productivity and control
Micro frontend architecture enables better control over the team development process. Product owners can better monitor non-functional requirements, such as page performance, and pinpoint the team responsible for a bug or failure. This leads to faster feature development and testing.
Faster time-to-market
Smaller and independent frontend components enable more focused development, parallel development, and incremental releases reducing the time required to bring new features to the market. By iterating quickly on features, companies can ensure their product responds to changing business requirements.
Micro frontend benefits for CTOs
Greater flexibility, scalability, extensibility etc.
The independent deployment and scaling enable CTOs to experiment with new technologies and frameworks without risking to disrupt the entire application. Micro frontends also enable quick iterations on frontend features and rapid response to changing business requirements.
Long-term maintainability
Micro frontend architecture can improve maintainability by providing smaller, more focused frontend parts. This approach makes it easier to understand and update the codebase, reducing the risk of technical debt.
Micro frontend challenges
Micro frontends have numerous benefits, so it’s easy to assume they are always the best solution for your frontend architecture. In reality, this is not the case. The micro frontend approach does not possess the ability to solve all of your problems. Therefore, when deciding whether to go for the micro frontend approach, it’s essential to address its challenges first.
Payload size
Micro frontends duplicate dependencies and bundle frameworks and libraries, increasing the web app’s payload size. Although this factor is a significant challenge, the web page on micro frontends will download faster than that on monolith architecture.
Some partial solutions include careful cashing on resources, meticulous selection of dependencies, and careful separation of rarely used pages.
Cross pages communication
Communication between micro frontends is hard to implement and maintain but there are cases when separated pages need to communicate at a minimum level with each other. One part of the application needs to be notified by the host or other micro frontends about user interaction and that it needs to change, refresh or trigger an action.
Design differences
If separate teams work on each micro frontend, they might not see the whole picture. As a result, the website’s pages might look like they are composed of many patches, inconsistent in terms of style, and UX/UI.
There are also ways to address this issue – to create common components, a style guide all teams can consult, or simply communicate with each other.
Operational complexity
Finally, adopting micro frontend presents operational complexity because such an approach to frontend architecture presupposes more repositories, tools, more build/deploy pipelines, and more complex infrastructure to make it all work together.
When not to use micro frontends?
Your project size is small
For small and simple websites, implementing micro frontends would be excessive and could unnecessarily complicate the development process. Monolithic architecture should work just fine.
You have a high risk of poor communication
If there is a risk of duplicating specific implementation methods with separate teams, you better think twice before implementing micro frontends. It may be a good option to begin with a monolithic approach and migrate to micro frontends later.
So, before blindly choosing micro frontends because they’re trendy, please remember that they’re complex and challenging to implement. To determine if micro frontends are truly necessary for your situation, consider the following questions:
> Will the micro frontend approach help your organization address the current pain points in the website development process?
> What specific benefits are you hoping to achieve with a micro frontend approach?
> Are you comfortable with decisions around tooling and development practices becoming more decentralized and less controllable?
> How will you ensure a minimum level of quality, consistency, look and feel or governance across your many independent frontend codebases?
Implementing micro frontend architecture with Euristiq
We had the opportunity to work on an impactful project involving micro frontends for Europe’s largest airline. The airline’s main website had a legacy architecture that was hampering their business operations. It was concluded that migrating to a micro frontend architecture would significantly benefit the airline.
We decided to use the approach of loading separate applications, which ensured the highest level of separation, and began the migration process. Due to the high degree of independence, the migration began with one page. We helped redesign it and deployed it without disrupting the entire system. The pages became isolated applications and loaded based on routing. We continued to progress gradually, altering other pages that weren’t performing well. Each page became independent, and its performance could be assessed separately.
The entire migration process from monolith to micro frontend took two years to complete. As a result, the modernized website showed a 3x improvement in performance and a 13x increase in page speed. The airline was able to carry out A/B testing, implement analytics, and personalize user experience on certain pages.
Explore Euristiq case studies and contact us to discuss your project needs. We can help you create exceptional digital experiences for your customers.
FAQ
What are micro frontends?
Micro frontends are an architectural design approach to frontend web development. The frontend app is decomposed into self-contained modules or features that are loosely connected and semi-independent. They can be owned by different frontend teams and deployed separately from other features. The concept is inspired by microservices.
How is micro frontend architecture implemented?
Micro frontend architecture is implemented by breaking down a frontend application into smaller, loosely coupled modules or functions. These modules communicate through well-defined APIs or events. To implement micro frontends in a monolithic app, begin by identifying decouplable features. Extract and refactor these features into separate codebases with their own build and deployment processes. Establish communication between the micro frontends and create a shell as their entry point. Gradually migrate and integrate the micro frontends into the shell application.
When would you use a micro frontend architecture?
It is most beneficial to apply a micro frontend architecture approach with large and complex applications when you are trying to achieve team autonomy, technology diversity, and scalability.
What is a micro UI?
A micro UI, or micro user interface, is a small, self-contained user interface component that can be developed and deployed independently. It is typically used within the context of micro frontend architecture to represent a specific part or feature of a larger application. Micro UIs are designed to be modular, and reusable, and can communicate with other micro UIs or components to create a cohesive user experience.
Rate this article!
out of 5, ratings.
Loading...
