Micro Front-Ends, yet another web development trend

9 min readOct 29, 2021

As of now in 2021, It feels like web development and its technologies are at their peak. I’m mostly talking about front-end development which has been growing really fast in the last 10 years. One of the hottest trends in 2021 is micro front-ends architecture. The idea first came up around 2016–17. In this article we’ll introduce you to micro front-ends and some principles and best practices in client side applications. We’ll then review some pros and cons and challenges of it. Finally in the end we’ll take a look at Twitter to see what people are thinking about micro front-ends.

An introduction to Micro Front-End architecture

Micro front-end extends the idea of micro services in back-end. But it’s a little bit different in the client side. The idea was popped up when all monolithic front-end projects were getting so big and hard to develop. In micro front-ends, your front-end app breaks into smaller and independent apps which can be developed, tested and deployed independently. The integration of these micros is your main application. This happens when you can distinguish different logic and complexity in your app that it can be divided to separate parts and these parts are not related to each other at all. In the ideal use case, your team has more than 4 or 5 front-end developers. With the help of this architecture, you can assign separate small teams by size to each micro application. In this case, separate teams are working on independent apps and their development process won’t interfere other teams. There can be many forms of slices in micro front-ends, but the best one is that each micro app is a SPA based on a certain business functionality.

In micro front-ends there is a container or parent application that all other micros are subsets of it. In the container application, several micros will be called and rendered based on certain scenarios. Also it is clear that some configuration e.g. routing should be done in the container application.

Challenges

How to avoid rework?!

In front-end applications, it is quite possible that some UI elements are used in multiple parts of the app. It is more common when we have a design language. For example you would use inputs or buttons with the same design multiple times. Some frameworks and libraries like React are constructed on the basis of this concept. React is nothing but components. Small and big components which can be embedded in each other to make pages. These components can accept arguments and be configurable both in the logic way and design way. This leads us to the concept of reusable code. You can write reusable components so that your codes are cleaner and development gets faster. These are all about avoiding code duplication!

So we have shared and reusable components in our app. Here is the question. When we break our application into smaller and separate apps, how do we use these shared components? Should we write them again in each micro from the scratch? The answer is a big NO! One of the best ways to overcome this challenge, is to write a library or package that includes these components. For example we write a npm package that each team can install it and use any module it wants. This is simple at the first look, but writing a package for UI components can have many challenges itself, especially if your UI logic gets more complicated in each component. In addition to that, writing a global library for a project which has not started yet, is impossible. It should get better time to time with multiple releases. All in all it’s recommended to start with simple components with less or not any JS logic at all e.g. icons or buttons. As the product is going forward, you may feel the need to improve the library and the best case is that each team can contribute to it and there are some people in charge of reviewing their contribution and interaction with them if necessary.

Developing a shared library can reduce rework in code and create a good design standard (style guide) among developers and designers.

Setting the standards, a big challenge!

One of the biggest challenges is to set global standards in all micro applications. These standards are mostly aimed for clean code and using best practices. For example code formatting or CSS classes naming conventions. These could get serious and result in bugs in your application. For example if you have two CSS classes with the same name from two different micros and somehow one overrides the other, we are facing a bad situation. Of course there are solution to that. You can use nesting feature in Sass, use BEM or some CSS-in-JS libraries. So we should be careful about having standards because there is not just one unit application.

Testing, easier or harder?

Micro Front-ends gives you an isolation over different modules of your app and thus it might be easier to test modules (writing unit tests). The main challenge is to test the micros-container integration. Testing your local logic and rendering (in the level of components or modules) is of the highest priority by the way.

Different environments

Mini applications that each team are working on, is not what exactly is seen in production. It’s a part of it. Therefore what developers see in the development mode, is not necessarily what is deployed.

Micros sharing something?

The main idea is that each micro should not be in contact with the others. But this can be possible and may have implementation challenges. In this case we should be careful about coupling issue because we are keeping modules in contact with each other.

Communicating with back-end

At the first look, it may seem that we have independent micros in the client side so why wouldn’t we apply the same architecture with a micro service and a database for each micro front-end in the back-end? The answer is not easy. Back-end architecture is not a concern for front-end developers. After all if the communication is REST, the only thing that matters is the end point that we fetch data from. I recommend you to read Martin Fowler’s article on micro front-ends as he addresses about extending the BFF (Back-end for front-end) pattern to micro front-end architecture.

DevOps challenges

As we have separate repositories and CI/CD pipelines for each micro app, we’ll have challenges as regards to deployment. We are not specifying a domain for each micro app and they should be loaded in the container application. In the end, the container application goes on production without letting users know that it is not indeed a monolithic application.

Few existing implementations

Here are some famous corporations using this technology:

Spotify
IKEA
DAZEN

It’s obvious there is not much variety of implementations right now. So this makes our migration to micro front-ends a challenge. It means that some implementations are not mature enough yet.

Benefits and downsides

Some benefits include: faster development with more concentration on several micro apps after the separation, smaller and more readable code base, easier software releases as the deployment is completely independent etc.

We mentioned some challenges in the previous part which could be considered as downsides too. But another issue that comes to my mind, is the bundle size and performance. There is no unit standard implementation for micro front-ends, so there’s a high chance that we end up in a messy project with a big bundle size and bad performance. It is all up to implementation methods. Another downside could be operational and governance complexity as the number of repos, tools, servers, domains and so on comes up. We have the same issue with micro services in the back-end.

Before wrapping up this section, I want to point out another issue which could be a benefit or downside both!

You are free to pick any technology of your choice in each micro; is it a benefit or downside?!

One of the main ideas of micro front-ends is to give developers the option of choosing any technology or framework they want. In the end everything is HTML — CSS — JavaScript and it’s not a concern for developers that what frameworks other teams are using. For example imagine an application with 3 micro apps. Micro A is built with React, micro B is built with Angular and micro C is built with Vue. The variety could get out of control. But is it a benefit or downside? No need to mention that the differences in the version of dependencies is another issue!

The only answer that comes to my mind is that don’t overuse this feature. If you are free to do something, it doesn’t mean that it’s necessarily a good thing!

Why would we pick micro front-ends architecture?

Here are some reasons:

Increasing the number of human resources in a product.
Unintended impact on other parts of the software in the development process.
Uncontrollable and large front-end code base.
Progressing the different parts of the front-end app each with a completely separate and different logic as the number of features are increasing.

In the end it is all up to your product and its requirements. A technology being trend doesn’t mean that it fits your requirements! Migrating to micro front-ends could be a dangerous decision if we don’t pay attention to the costs and downsides.

Micro front-ends in the social media

Some days ago I searched the keyword “microfrontends” on Twitter to see what developers are talking about it. These experiences could be interesting as some of them have used this technology in their work. I will put the links below and highly recommend you to read the comments. I really enjoyed the discussions in the comments.

Here in this tweet people think that it just makes the web development harder than it has to be. See tweet

2. In this thread, the author sets some rules that thinks it will make the most out of micro front-ends architecture. See tweet

3. A bizarre experience of a developer that says their project ended up with 11 MB of bundle size. See tweet

4. Dan Abramov compares micro front-ends with the idea of web components in React. In the comments, some say that micro front-ends doesn’t solve any technical problems, but only business ones. Some others say that with React’s architecture we don’t need micro front-ends. See tweet