What Are Micro-Frontend Web Applications?
Table of Contents

What Are Micro-Frontend Web Applications?

Micro-frontends (MFEs) are a hot topic in web development circles these days. But what are they? In a nutshell, MFEs are a way of structuring a web application as a collection of small, independently deployable modules. Each module has its own UI, business logic, and data model, and can be developed, tested, and deployed independently of the other modules. Although micro-frontend as a term has been used in multiple articles and projects in the past, it wasn’t until Zack Jackson released the master plugin called Module federation in 2020 that the campaign for the concept really kicked off bringing widespread adoption and attention.

The Benefits of Micro-Frontends

There are several benefits to using the micro-frontend architecture in new and existing projects with the most obvious of them is having greater flexibility and modularity in the design of your user interface and presentation layer. Each team can develop its own UI components without having to worry about breaking the features of other teams. Some other benefits include:

  • Better separation of concerns. Each team can focus on its own area of the application without having to worry about the implementation details of other teams.
  • Easier parallel development. Multiple teams can work on different parts of the application at the same time without having to coordinate their efforts.  
  • Easier, simplified testing and debugging of individual modules. Each team can test and debug its own UI components without having to worry about the components of other teams.  
  • Better performance. Each team can optimize its own UI components without having to worry about the performance of other teams.
  • Scalability and scaling related issues can be resolved easily. Each team can scale its own UI components without having to worry about other teams, components or modules.
  • Deployment. Each module can be allocated resources as deemed fit without affecting other parts of bigger application, with each module deployable individually making it the perfect candidate for efficient management of resources.  

The Drawbacks of Micro-Frontends  

There are some drawbacks to using the micro-frontend architecture with the most notable being the possibility to produce a lot of code duplication if not done carefully and sometimes inevitable challenges with managing and sharing data between the components. Some other notable drawbacks are itemized below.

  • Difficulty with keeping different modules in sync with each other. If one team makes a change that breaks the interface between two modules, it can be very difficult to track down the source of the problem.  
  • Difficulty with testing the full application or debugging it. When there are multiple teams working on different parts of the code, it can be hard to reproduce the conditions under which a bug occurs.  
  • Micro-frontend architecture can make it difficult to share code between different parts of the application. If each team is working in isolation, it can be hard to reuse code that has been developed by another team.  
  • One could argue that the pattern is form over function.
  • Ironically, it may be difficult to integrate different components together, if they depend on one another. To make this a non-issue, establish cross-team best practices and conventions.

Finally, following the micro-frontend architecture can be difficult when it comes to deployment and keeping track of the current state of the overall application. If each team is responsible for deploying their own code, it can be hard to keep track of what happened where and when, creating confusion about what is the actual state of the application on a higher level.

All the downsides can be properly managed by using different tools and processes that are better suited for the job, however, some of which are covered in this article and others through further research.

How to Implement the Micro-Frontend Architecture.

There are several different ways to implement micro-frontend modules or components. The most common approach is to use a JavaScript library such as React, Vue or even SSR (server-side rendering) libraries and tools. Each team can develop its own UI components using the library of their choice and then use a tool such as webpack or rollup to build a single bundle that includes all the UI components.  

Another approach is to use a framework such as Ember or Angular which helps to properly organize the components and make them easily detachable. It is important to note that with micro frontend architecture, each team can develop its own components using the framework or library of their choice and then use a tool such as webpack or rollup to build a single bundle that includes all the components. Examples of implementing micro-frontend architecture are widely available and one of the popular sources is the module federation examples repository on GitHub see https://github.com/module-federation/module-federation-examples for more information.

Storing and Sharing Code

Monorepo is one of the widely used setups when working with git-based code repository. This concept allows access to other components locally and allows developers to easily make changes to components without additional efforts. Some teams, however, do not share code repositories and still work efficiently. One must consider how often the teams interact, how related the components are and decide on how to organize the code based on this information. It is also important to properly divide the components in such a way that they are as independent as possible code wise, data wise and feature wise.

Shared components or features could be organized in separate repositories or in a single repository separated by folders, it is recommended however that they are versioned. If a team changes a specific shared component, it should be reflected in the version of the component that is built after the change. A proper change log describing the change to the shared component should be kept ensuring effective documentation of changes made.  

Individual components into single app or container

Aside from using build tools like webpack with the help of module federation, other tools such as React Router, Angular Router, Next.js, Astro or even Nginx can be used to create a single-page application which we will refer to as the container app. This set up usually includes all the components and acts as an entry point to the project. Each team can develop its own UI components and then use the choice tool to route between and present the different components as a single deliverable project or multiple small projects. It is important to note that making a container app requires additional effort such that some organizations assign the container app project to a dedicated team.  

Building and Deployment  

There are many options available when it comes to building the individual components, in most cases, the default build tool for the library or framework is usually enough. In other cases, third party tools like webpack can be integrated.  

All components should have their dedicated build process or stage either as part of a bigger pipeline or individual pipelines. This allows the components to be truly independent and deployable separately. Teams can leverage containerization e.g., Docker to help organize the deployment process and builds. Each change to a component could be versioned using semantic versioning and deployment of version updates can be automated, controlled or manual depending on the business requirements.

For the most part, existing pipeline solutions such as GitLab and GitHub Actions, Jenkins and the likes should be sufficient for building and deploying individual components. It shouldn’t matter if they are deployed to the cloud or custom servers, pods, azure app service or even as files on s3 bucket, existing solutions should be sufficient as they are highly customizable to accommodate splitting a big project into smaller parts.

Individual components could also be deployed to private package registries such as nexus using NPM or other options available. This way the components could be easily imported, built and managed. Teams can decide which versions of third-party components they want to install and track the history of changes. This is especially useful for shared components and services.

It is important to note that while using webpack or rollup to build a single bundle that includes all the UI components from all the different teams is a good thing since it allows you to use any JavaScript library or framework, it does require you to have a build system in place that can handle the different dependencies effectively.

Exposing MFE modules for public access

The container app mostly serves as the entry point of micro-frontend applications. Users will visit the container app which in turn decides which micro frontend component to render based on user interaction. Sometimes, the container app could contain a menu, header component and necessary structure needed to present the application.  

Aside from using existing solutions built into frameworks and libraries for data transfer, routing and building a container for your components, a container apps can also be a simple or complicated Ngnix server, Express app, Astro project amongst other options available as their core role is to route traffic and present different components running on dedicated ports, url within the local network, Kubernetes clusters or public network. Different parts of the app could have their own firewall configurations, access levels, rights and still work together effectively without problems since each one will be running on its own mini network, container and port, rules can be applied on top level, load balancers can be configured, and traffic can be managed seamlessly.

Sharing Data

Sharing data between different modules and components in an MFE based application can be tricky. There are some important parts to note and some basic rules that apply. For the most part, a state manager can be employed to help with data management of local components as well as sharing data between external components. State management tools like Redux perform well with micro frontend components as each team can manage their local data within their components and in addition expose possibility to share the data. In Angular, tools like RxJS and services with observables can be used as opposed to using an external state management tool to manage and share component data seamlessly.

One of the important things to note is that data should be segregated as much as possible, making them independent and unique to individual component should be the goal when receiving data from third party API’s or from user input. Minimizing the amount of data shared between the components and ensuring that shared state is managed in such a way that only the component responsible for modifying it has written access while others only consume / read the data. Updating data when multiple components are involved in the update should be done in a queue like manner where the first update to arrive is applied follow by the next to create a smooth transition of state and generally efficient system.
It is also important to ensure that components can ignore unnecessary data, events and changes in data that might cause them to re-render when no direct changes are made inside the component. Implementing efficient change detection strategy and unsubscribing to data stream when they are no longer needed should strongly recommended.

Best Practices for Micro-frontends

There are some best practices that should be followed when developing a micro-frontend application.  

  • Each team should develop its own UI components in a separate repository. This will allow each team to work independently and will make it easier to share UI components between teams.  
  • Each team should use a tool such as webpack or rollup to build a single bundle that includes all the UI components. This will make it easier to deploy and update the UI components.  
  • Each team should use a consistent coding style and naming convention for their UI components. This will make it easier for other teams to understand and use the UI components.  
  • It is important to use a micro-frontend framework that will allow teams to easily share data and state between UI components. This will make it easier to develop complex applications that are composed of multiple micro-frontends.  
  • Each team should unit test their UI components. This will ensure that the components work as expected and will help to prevent bugs from being introduced into the application.  

In conclusion, micro-frontend architecture is revolutionizing frontend development, presentation and management. It presents some exciting possibilities that everyone wants to be a part of. It is crucial that proper research is carried out before converting existing projects or making new projects leveraging the MFE architecture.  

Liked the article? subscribe to updates!
360° IT Check is a weekly publication where we bring you the latest and greatest in the world of tech. We cover topics like emerging technologies & frameworks, news about innovative startups, and other topics which affect the world of tech directly or indirectly.

Like what you’re reading? Make sure to subscribe to our weekly newsletter!
Relevant Expertise:
No items found.
Share

Join 17,850 tech enthusiasts for your weekly dose of tech news

By filling in the above fields and clicking “Subscribe”, you agree to the processing by ITMAGINATION of your personal data contained in the above form for the purposes of sending you messages in the form of newsletter subscription, in accordance with our Privacy Policy.
Thank you! Your submission has been received!
We will send you at most one email per week with our latest tech news and insights.

In the meantime, feel free to explore this page or our Resources page for eBooks, technical guides, GitHub Demos, and more!
Oops! Something went wrong while submitting the form.

Related articles

Our Partners & Certifications
Microsoft Gold Partner Certification 2021 for ITMAGINATION
ITMAGINATION Google Cloud Partner
AWS Partner Network ITMAGINATION
ISO-IEC 27001:2013 ITMAGINATION ISO 9001 ITMAGINATION
© 2024 ITMAGINATION, A Virtusa Company. All Rights Reserved.