Introduction to micro frontends

Have you ever worked on a project with such a complex frontend that you accumulated a lot of technical debt? 

There’s a better alternative. Instead of using the typical monolithic architecture, you can split it into smaller, more easily manageable applications known as micro frontends. 

In this article, I’ll tell you what they are, what benefits they can bring, and what challenges to watch out for. 

What is a Micro Frontend?

The main idea is to split a traditional Frontend Monolith application into multiple smaller ones.

As the development team tries to develop a larger, more scalable application, maintaining the codebase and managing deployment releases becomes increasingly tricky. Certain types of testing, such as regression tests, also become more time-consuming. 

Micro frontends are mini-applications that implement a subset of features into a root app, ensuring the smaller parts work together. They’re a type of microservice that exists within the browser. 

They represent sections of the UI, consisting of components usually developed with frameworks/libraries such as React, Vue and Angular. Each micro frontend has its own git repository, dependencies and build tools and can be developed independently.

Example use cases

Now that we’ve covered what micro frontends are, let’s look at some ways you can use them in your work. 

A domain and its sub-domains as micro frontends: A root application defines routes, each of which is served by a different application. Furthermore, a default path can be defined, serving as a 404 page shared between each micro frontend.

https://public.domain/sub-domain-name1 // micro frontend #1 https://public.domain/sub-domain-name2 // micro frontend #2

A sidebar or another type of navigation: You can have each navigation link lead to a separate micro frontend. In this case, common functionalities will be grouped together and form one micro frontend, and you can implement other features in additional ones. For example, look at the diagram below. The Products page can be implemented in one micro frontend; the services can be in another, and the remaining pages (Home, About Us, FAQs, and Contact Us) can be grouped and implemented in a separate one.

A selection of elements/components that form a parcel: They can be separated from the application and moved to a micro frontend. For example, an e-commerce website can have a chat feature enabling communication with a potential customer. 

Benefits of using Micro Frontends

With all of that said, why should you use micro frontends? What makes them better than other architectural approaches?  

Separate teams can work on different micro frontends simultaneously: You can have separate micro frontends for the product details, shopping cart and checkout functionalities. That way, different teams can work on each project at the same time. 

Each application can be developed using different frameworks: It doesn’t matter what framework you’re using. It could be React, Angular, Vuejs, or even different versions of the same one. Regardless of the frameworks and their version, they can be seamlessly integrated into the main root application.

The opportunity to migrate legacy code using a new framework or the latest version of an existing framework: If a micro frontend that uses old versions of a framework and packages has become too large, you can move some of its features to a new one, using the respective latest versions. 

The ability to deploy micro frontends independently: It becomes easier to determine why a deployment build could fail. Micro frontends also help plan smaller releases and subsequently deploy fewer features to test.

Lazy load code for improved initial load time: Lazy loading is an optimization technique that only downloads the JS code needed for the current page. A framework such as single-SPA provides lazy loading functions out of the box. And since a micro frontend is an in-browser module, the user downloads only the necessary in-browser modules.

Import map and Local development

An import map is a mechanism for fetching URLs of Javascript import statements and expressions. Import maps with the addition of import-map-overrides (a tool for overriding import maps) are useful for local development. Typically, a developer would override the import map for the micro frontend they’re working on, and use the deployed versions for all the other micro frontends. 

{   “imports”: {     “@product-listing”: “https://localhost:[port_number]/product-listing”,     “@shopping-cart”: “https://[production_url]/cart”,     “@dashboard”: “https://[production_url]/dashboard”   } }

Challenges

As with anything, a micro frontends approach comes with certain challenges. Let’s take a look at the two most common ones: 

Splitting an app into smaller apps can have its drawbacks: For example, there could be an issue with inconsistent behaviour throughout the entire app, where similar components are used. This could involve forms and how the users interact with them, the styling of buttons, paragraphs, headings, or other elements. These issues can arise if there isn’t an appropriate design template or specification. Ideally, all teams should follow the same design principles. Regardless of frameworks, establishing a standardized design will preserve consistency across the micro frontends where common web components are shared.

Communication across teams could be problematic: Certain functionalities may require some interaction between different micro frontends. For example, there could be two types of users that log in to the system, where one user is presented with different menu options and have access to a different set of features, compared to the other type of user. One feature could be enabling file sharing between each other. This will require some communication and agreement regarding allowed file extensions and file size.

Conclusion

Adopting a micro frontend approach can be beneficial when a client has an array of applications that comprise their core business functions, and development needs to be split between different teams. It makes releasing and testing new features much easier, as each micro frontend has its own deployment pipeline. The main challenge is ensuring that the design principles and behaviour of components stay consistent. 

However, if you’re a single smaller team developing small or medium apps, a micro frontend architecture would most likely add unnecessary complexity. In such a scenario, it would be more manageable to release new features, ensuring clean code practices and standard design guidelines.