Micro frontends: pros and cons

Contents

Developing the frontend of your page or app can be hard work, especially with such factors as team size and project complexity. Scaling the forepart in order for several teams to simultaneously work together on a large, complex project is often challenging for businesses. However, a technology trend such as micro frontends makes it possible to scale the frontend and increases the efficiency of development teams working on the code. This article gives an overview of micro frontends, highlighting the architecture’s pros and cons.

 

What is micro frontend architecture?

It is an architecture type where the web app is split into different modules or isolated functions and implemented autonomously, thereby giving frontend teams ease of flexibility and speed. Each individual micro frontend application is responsible for its own function, but they come together to form the entire client-side user interface: each frontend is a chunk of the entire application, but unlike in monolith architecture, does not constitute the whole.

 

How micro frontends work

Developers working on the different parts of a monolithic frontend have a lot of plates to keep spinning, as the applications they work with feature components and applications that are all interdependent and contained on one web server. Even if they have their own separate DevOps plans and teams to concentrate on, the fact they are all housed in the same monolith causes issues arising from interdependence and cross-cutting concerns. Other teams working on the same project can sometimes accidentally work against colleagues or create problems in the code or database as a result.

However, when concentrating on a single micro frontend component, teams can work on and deploy each module independently during the frontend development process, resulting in the benefits of an autonomous team.

The various APIs or functions are assembled together to create the front page. The front page is therefore something that emerges from a collection of separate features, with no accompanying issues of interdependence or teams working across multiple parts of the same whole and potentially making mistakes with implementation details.

Each developer team, if given its own concrete set of KPIs and web component specs for the custom elements they are working on, can concentrate exclusively on its own portion of the whole client-side interface, without issues arising over team conflicts. As we will see, this also has attendant consequences in terms of deployment, scaling, testing, and modularity.

The concept behind the micro frontend framework is to:

  • Create isolated team code: Teams never share runtime, even if they use the same framework. This allows them to build independent and self-contained applications without relying on shared states or global variables.
  • Be technology independent: Each team can choose and upgrade its tech stack without coordinating with other teams. With the custom elements, it is possible to hide implementation details while still providing others with a neutral interface.
  • Resilient web design: Build resilient web features that are useful, even if JavaScript has not yet been executed or has failed. Teams can use progressive enhancement and universal rendering, which are considered ideal to improve performance.
  • Opt for native browser features: Use default browser features rather than custom APIs. For instance, instead of creating a global PubSub system, use Browser Events to communicate. In case you really need to develop a cross-team API, then it should be as simple as possible.

Benefits of micro frontend architecture

Pros of this architecture include:

#1 Library development

Different teams who have tested and deployed the components that they are responsible for can reuse the frontend code and so reintroduce the components into other projects. This allows for the creation of that company’s own library ecosystem of web components and web applications.

#2 Flexibility and variation

Developers can choose different types of frontend frameworks, such as React or Vue, or programming languages they would like to employ in the creation of the frontend they are responsible for. This allows for maximum flexibility for developers to choose the systems they prefer and are most comfort with, leading to insightful and dynamic thinking, as the project does not then have to adhere to the same framework or programming language throughout. With no technology lock-in, there is no risk that your business will be stuck with a legacy framework during the whole application life cycle.

#3 Speed

If the project has enough resources to employ enough frontend teams, then the app can be created quickly with teams working on their own micro frontend components, goals, and deadlines, and being responsible for their own testing and deployment.

Unlike feature-rich web solutions with a monolithic architecture, the micro frontend approach promotes page load-time optimization. The efficiency of this architecture is enhanced by multiple smaller bundles for web pages. As such, the browser is not forced to download unused code each time, resulting in faster page load times.

#4 Scalability

If the app or page is complex, it will need scaling over time. Again, if the resources of the project allow for multiple teams, then these teams can work on and grow their own frontend portion with incremental upgrades, leading to the app scaling at a manageable pace over time with multiple teams responsible for their own designated micro frontend implementations.

Making major changes in a frontend monolith comes with significant risks, as one wrong move can make all the features go down. In this case, making modifications is not easy so is usually avoided unless necessary. Micro frontends are the opposite, and each idea can be independently implemented or upgraded regardless of the complexity.

#5 Developer experience

It is much easier to learn the code required for a single microservice than for an entire monolith. Also, developers can choose the language they are most familiar and comfortable with when working on their components. This allows businesses access to a greater pool of potential staff, potentially working on multiple applications, as they need not rely only on the most experienced members. This also has corresponding advantages for budget considerations.

#6 Independent deployment and testing

Teams deploy only the component that they have developed. Because the frontends are independent, it means that deployment and other changes can affect only that specific microservice, and cannot cause changes to the whole. This also ensures that teams are responsible only for the testing and monitoring of one aspect of the whole, so avoiding the need for the entire project to be monitored and tested at the same time.

#7 Cleaner code

Monolithic frontends have complex code bases that tend to become more unstructured over time and hence become more challenging to maintain. However, using a frontend framework helps solve this issue as each individual micro frontend source code is simpler, smaller, and easier to manage. Consequently, this results in more structured and cleaner code that is easier to maintain.

#8 Higher app stability

Since the components are coupled loosely and each coupling is deemed meaningful, this leads to advanced stability in the web application. Alternatively, loose coupling reduces the impact of the failure of one component on the operations of the other components.

#9 Modernization

This architecture allows each component to be independently replaced or updated, enabling organizations to easily modernize their applications incrementally. As a result, micro frontends help to promote app modernization, as it significantly reduces the risks associated with legacy overhauls and enables organizations to use new technologies implemented at their own pace.

Drawbacks of micro frontend architecture

Even though micro frontends have lots of benefits, using this architecture approach comes with a number of drawbacks:

#1 Increased resource demand

For the above advantages of micro frontend architecture to be realized, the project must have access to multiple teams. If a business does not have the sufficient size or resources for micro frontend projects, then this framework would actually prove to be more cumbersome and demanding than simply using a monolith.

Furthermore, using this architecture may require additional management effort and infrastructure for scaling, continuous independent deployment, and monitoring, especially when implementing complex projects. This can lead to increased operational costs due to greater resource requirements.

#2 More complex development

For the team code to be correct, effective for use, and easy to read through, it needs documentation and unit tests. This is because the framework requires disparate tech stacks and inter-component communication. If micro frontend architecture is not well-implemented, then each separate module risks being complex, making web development a challenging aspect for developers.

#3 More complex deployment process

Upgrading or deploying changes to your web application can become more challenging when using multiple micro frontends. This is because it requires a better understanding of the underlying dependencies between the modules for them to be deployed together in the correct way. Additionally, each module might require the orchestration of several deployment pipelines. This can result in conflicting updates that may lead to performance issues.

#4 Payload

The microservices employed can result in the need to duplicate common dependencies. This means, for example, that if a micro frontend requires a specific program to be installed in order for it to function, then client-side users are also required to download a corresponding copy. This is true for each component, meaning there might be multiple download requirements to ensure complete functionality and browser support.

This is an issue because many user contexts rely on infrastructure that is poorer in performance than that used by the developers, so extra data demands are a disadvantage—users will not return to web applications that have poor page performance. Using components that have the default web browser’s support can help remedy this effect, as this reduces reliance on downloads.

#5 Poor user experience

A pleasant user experience requires consistent and cohesive understanding across multiple teams. However, using a micro frontend might involve different groups of people using multiple technologies within the same project. Inconsistency in one area means that others will experience similar effects, resulting in an overall unpleasant user experience. To maintain a unified user experience, the teams should strictly adhere to the design guidelines while maintaining regular cross-team communications.


When to use micro frontends

A micro frontend framework is not an all-in-one architecture approach for mitigating all your pain points and is mainly ideal for use with:

  • Medium-to-large projects: The architecture is ideal for medium to large-scale projects with multiple functions. The style used in building a micro frontend makes it suitable for scaling complex projects and as such makes it a suitable fit for large development teams.
  • Web projects: while micro frontends are versatile and not platform specific, they offer the best performance on web projects. This is because native applications for Android and iOS have monolithic architecture, hence it will not be easy to compose and replace functionalities.
  • Productivity-oriented projects: micro frontends promote vertically sliced developments, which are known to enhance the overall project productivity.

Micro frontend use cases

Some of the organizations that use micro frontends include:

 

#1 IKEA

A key success factor with how the micro frontend works is being able to keep the autonomous teams small. In addition to that, this architecture makes the frontend code development process easier by breaking it down into smaller parts, allowing teams to autonomously deploy, leading to continuous delivery of web applications.

 

#2 Zalando

Apart from selling its products online, Zalando also heads Project Mosaic, a specialized micro frontends middleware featuring a set of libraries and services supporting a micro frontends type of framework that supports server-side rendering. Mosaic offers great control over page performance and failover.

 

#3 Spotify

Micro frontends are used for Spotify’s desktop applications, leveraging iframes to join together different sections of the same view. Communication between iframes is supported by an event bus that seamlessly decouples the different application parts, leading them to communicate without knowledge of who will listen to an event or a message.

 

#4 HelloFresh

The internal teams of a meal-kit company’s have been able to overcome project complexity issues and innovation barriers by breaking down the frontend monolith. Previously, the company had a huge monolithic application that was challenging to maintain and to boot in a local environment. However, each project now has its own isolated development environment and server. Micro frontends allow teams to work with smaller and more manageable codebases that are comprehensible. This enhances productivity and minimizes the complexity of their work.

 

#5 DAZN

The sports streaming service has used micro frontends to empower its workforce by creating smaller independent teams. This approach has made it easier to scale teams and build more resilient applications.

 

Best practices with micro frontends

In the current digital era, the frontend is getting bigger and becoming more important with the development of new modern web applications. Best practices for implementing the micro frontend architecture include:

 

Workflow organization

The most crucial part of web app development is to empower your team and ensure it can deliver independently. This means that project objectives and responsibilities must be set and agreed upon by everyone. Additionally, it is important to create consistent and well-structured API contracts with other teams, fostering an environment that facilitates better collaboration.

Once all these measures are put in place, each team can work independently toward attaining its objective. It should be noted that all the business requirements should align with the modular delivery of the micro frontend framework. If that is not the case and your business needs to designate all components simultaneously, then you will underutilize modularity and the business will still have a monolithic organizational structure even though its architectural setup is modular.

 

Single-page application (SPA)

Every micro frontend should be used as a single-page application. Teams can create this system with multiple frameworks for SPAs such as Angular, ReactJS, and Vue that allow the combination of multiple development frameworks into a single page and without the need to update or refresh the page.

 

Apply API-first design principles

It is important to establish a clear boundary between the backend and frontend to ensure efficient development and smoother communication. Thus, adopting an approach that utilizes custom APIs allows newer independent teams to work without prior knowledge of what was built before.

 

Embrace automation

Embracing automation means teams can streamline the process of building micro frontends. automation ensures every component is integrated into the larger system correctly and meets the required quality standards.

Without building and deploying automation, your team could possibly experience stagnation. Therefore, investing in robust continuous integration and continuous deployment is critical. By using continuous integration, the involved team ensures that different web components are quickly tested and deployed independently. This can result in improved performance, reduced development time, and overall better quality. Also, continuous integration ensures that teams can easily collaborate by ensuring all the code changes are monitored and tracked.

 

Determine the right size of micro frontends

Each micro frontend implementation needs to be well-proportioned. Striking a balance is crucial and even though there is not a one-size-fits-all rule, if it is too small then you will face fragmentation, while too large and your web apps will be overly coupled. All decisions regarding micro frontend architecture and app segmentation should have a business purpose and be clearly defined in advance.

 

Do not overuse micro frontends

Determining the right size of your micro frontend ensures that you do not overuse it. In the case of over-application of this architecture, it could result in excessive application fragmentation, and this can potentially create limited value components.

 

Communication

Micro frontends should communicate with each other via a standard event bus. Therefore, each module should independently work on its own framework that will be responsible for handling incoming and outgoing events.

 

Component libraries

Regardless of the tech used in the main application, every module should be organized into libraries that will be used by the main application. This ensures that the main application is confirmed by various different components.

 

In summary

Using micro frontends for web application development leads to more flexibility, efficiency, and scalable code development, especially when dealing with several independent teams. This architecture provides a new and powerful way to modernize systems with greater flexibility and variation. Micro frontend source codes are also usually simpler and easier to maintain.

The architecture, which is ideal for medium-to-large projects, promotes overall project productivity and, as a result, has numerous use cases, including IKEA, Spotify, and Zalando. But despite its numerous benefits, micro frontends may result in increased resource demand leading to higher overhead costs. Furthermore, using multiple technologies within the same project can lead to poor user experience.

Thus, for optimal results, companies should consider optimizing workflows before using it to ensure that project objectives and responsibilities are agreed upon beforehand. In addition, the organization should be ready to embrace automation for quick testing and deployment.

This article was originally published November 24, 2021, and updated August 22, 2023.

Sign up for the newsletter and other marketing communication

You may also find interesting:

Book a free 15-minute discovery call

Looking for support with your IT project?
Let’s talk to see how we can help.

The controller of the personal data is FABRITY sp. z o. o. with its registered office in Warsaw; the data is processed for the purpose of responding to a submitted inquiry; the legal basis for processing is the controller's legitimate interest in responding to a submitted inquiry and not leaving messages unanswered. Individuals whose data is processed have the following rights: access to data, rectification, erasure or restriction, right to object and the right to lodge a complaint with PUODO. Personal data in this form will be processed according to our privacy policy.

You can also send us an email.

In this case the controller of the personal data will be FABRITY sp. z o. o. and the data will be processed for the purpose of responding to a submitted inquiry; the legal basis for processing is the controller’s legitimate interest in responding to a submitted inquiry and not leaving messages unanswered. Personal data will be processed according to our privacy policy.

dormakaba 400
frontex 400
pepsico 400
bayer-logo-2
kisspng-carrefour-online-marketing-business-hypermarket-carrefour-5b3302807dc0f9.6236099615300696325151
ABB_logo

Book a free 15-minute discovery call

Looking for support with your IT project?
Let’s talk to see how we can help.

Bartosz Michałowski

Head of Sales at Fabrity

The controller of the personal data is FABRITY sp. z o. o. with its registered office in Warsaw; the data is processed for the purpose of responding to a submitted inquiry; the legal basis for processing is the controller's legitimate interest in responding to a submitted inquiry and not leaving messages unanswered. Individuals whose data is processed have the following rights: access to data, rectification, erasure or restriction, right to object and the right to lodge a complaint with PUODO. Personal data in this form will be processed according to our privacy policy.

You can also send us an email.

In this case the controller of the personal data will be FABRITY sp. z o. o. and the data will be processed for the purpose of responding to a submitted inquiry; the legal basis for processing is the controller’s legitimate interest in responding to a submitted inquiry and not leaving messages unanswered. Personal data will be processed according to our privacy policy.

dormakaba 400
toyota
frontex 400
Ministry-of-Health
Logo_Sanofi
pepsico 400
bayer-logo-2
kisspng-carrefour-online-marketing-business-hypermarket-carrefour-5b3302807dc0f9.6236099615300696325151
ABB_logo