Tools and Practices for Micro Frontends
Today, Microfrontends are no longer a proof of concept. If we search on the internet, we can find many case studies of adopting Microfrontends. Besides, most of these web apps are already in production, proving its robustness.
However, it is essential to follow the best practices and choose the right tools to succeed with Microfrontends. Otherwise, Microfrontends could quickly become an overhead for your teams, risking the overall growth of the project.
In this article, I’m going to share some of the best practices around Microfrontends and recommend several tools to establish these practices in your projects.
💡 Consider watching this video before you begin:
1. Code Structure and Components
When adopting Microfrontends, one of the critical decisions you have to make is to choose the approach used to structure the code.
The two conventional methods used out there are the Distributedrepo and the Monorepo. Other than these two are hybrid approaches that fall somewhere in between.
In the Distributedrepo approach, the Microfrontends are divided into multiple repositories with their lifecycle managed separately. In the Monorepo, all the Microfrontends will reside in a single repository.
Distributed Repo Approach
The Distributed Repo approach is the more flexible one but it has the great challenge of sharing UI components, to maintain a consistent UI across MFs (which usually means maintaining UI components as NPM libraries, which creates the overhead of maintaining different build pipelines, different repositories, and version mismatches).
One good example of both implementing this Micro Frontends approach and solving the problem of sharing UI components between them, can be seen in Bit.dev.
The Bit.dev marketing website is composed using two groups of React components published and managed by the Bit platform. The two groups were built and delivered separately. The “moment of integration” happens on build time, in a codebase that consumes components from both collections. Whenever a new component version is delivered, a new integration happens.
Hover over different components on Bit’s landing page to see each component’s “scope” or “collection”. Click on the component name (on top) to inspect the component and/or to install it in your project.
As mentioned earlier, the above page is built from components developed in two different codebases, on two different GitHub repositories. Components of each codebase are published to their respective Bit collections.
- base-ui: Github | Collection on Bit
- evangelist: Github | Collection on Bit
The base-ui collection serves as Bit’s design system. Its components are also published to Bit. It’s worth mentioning that each component is published, versioned, and consumed, individually.
Components published to the evangelist collection (used for Bit’s marketing pages) use some of the components available in the base-ui collection, to maintain a uniform look-and-feel.
Monorepo Approach
If you follow the Monorepo approach, you won’t get into the same challenges of managing shared components as previously. But as the name suggests, all the teams will work on the same repository, where ownership of code segments needs to be clearly defined. Also, it is crucial to establish governance across code and dependencies between Microfrontends.
One of the best tools out there for the Monorepo approach is NX, Extensible Dev Tools for Monorepos. Currently, NX supports both Angular and React out of the box. The main advantage of NX is that it will provide the structure for Monorepo and the underlying toolset for DevOps and governance.
You can find more information on how NX works in practice referring to the video on Nx: Extensible Dev Tools for Monorepos.
2. Dependency Management
When building Microfronends, dependency management impacts the project in two ways. One common requirement is to manage third-party dependencies. The other element is to handle shared code like utilities and frameworks which fit well into NPM libraries (applicable for the Distributedrepo approach). These libraries, we need to publish to a repository to access from each Microfrontends, similar to third-party dependencies.
One of the best practices around managing both internal and external libraries is to use a private artifact repository. We can publish the internal library code to the artifact repository as well as to proxy the third-party libraries (also works as a backup) and deliver to Microfrontends from one place. Besides enabling access to libraries, using an artifact store will help to enforce governance around the versions used across Microfrontends.
One of the tools I would recommend for this is to use Azure DevOps Artifacts. If you are not using Azure DevOps for any reason, you can find several other tools that do the same job.
3. UI Theming
One of the standard practices around UI theming for web apps is to use a UI framework like Material, Bootstrap (or a specific implementation like NGX Bootstrap) &, etc. These UI frameworks provide the standard UI elements, styles, and the possibility of customizing the themes. In Microfrontends, it’s essential to keep the constancy of the UI components across to make the overall application theme look consistent.
Therefore, if you use the Distributedrepo approach, it is a best practice to export the theming, and standard UI elements to a private NPM library with CSS shared across Microfrontends. You can use Azure DevOps Artifacts for the same purpose.
4. DevOps
Using the right tools and practices in DevOps will show immediate results. Also, it is an area that has a diversity of tools and methods which you need to choose based on your underlying technologies and platforms. In this article, I will be touching mainly on CI/CD automation, Code Quality, Telemetry, and Monitoring aspects for Microfrontends.
CI/CD Automation
Using automation is essential both for Microfrontends and Microservices. With the additional complexity in place with Microfrontends, automation is the key that keeps the accuracy and speed of delivery.
In the context of Microfrontends, we need to set up automation for code builds, integrations (depending on the Microfrontend approach), and carry out the unit, and integration tests. One crucial step with Microfrontends is to validate the application works as a whole after deployment. You can use an end to end automation tool like Cypress to write the automation scripts to verify the web app functionality.
Since CI/CD is a commonly used practice, I won’t be highlighting any specific tools. But you can use any other means to automate, addressing the concerns mentioned above.
Code Quality
When we use Microfrontends, it’s essential to maintain the consistency in code and govern its quality. Unlike Microservices, you will likely use the same technology stack across Microfrontends. Therefore, it’s important to enforce rules to maintain code quality across Microfrontends.
One tool I could highly recommend is the SonarCloud, where it will help to establish a quality gate for continuous enforcement of code quality as well as to capture the overall quality matrices of the application.
Telemetry and Monitoring
For Microfrontends, I would recommend tracking the behavior of the Frontend itself. It is good practice to monitor the frontends as a practice since the risk of failure of Microfrontends is higher than a single frontend for apparent reasons. One of the tools I could suggest is to use Azure AppInsights using their JavaScript SDK to trace from Frontend to the entire Backend infrastructure. It suits best if your backend also uses .NET.
If you are on a different platform, you could probably find similar tools that do the same job. The most crucial factor is to have the tools in place to monitor the entire application without ignoring the Frontend part.
Summary
Overall, I hope you went through the best practices around Microfrontends discussed in this article. However, it’s important to note that these practices are continuously evolving, and it is vital to adopt these practices based on your application, team structure, and organization.
Also, there are various existing tools we can use for Frontend development, which are still applicable to Microfrontends. Therefore, don’t limit the tools mentioned in this article and try to investigate the possibility of using the tools you are familiar with in supporting the best practices discussed in this article.
At last, its essential to understand that Microfrontends is not the best choice for everyone. Therefore, before adopting Microfrontends, do your background research whether you are at the right stage and having the right match towards selecting Microfrontend architecture for your application.
