MFEs – a solution for scaling development

MFEs – a solution for scaling development

default avatar
Thought by Radoslav Radoychev
July 21, 2022
micro-frontends

Have you heard of micro-frontends lately? The idea behind MFEs is to think about a website or a web app as a composition of features which are owned by independent teams. It is an architectural style where independently deliverable front-end applications are composed into a greater whole. Learn how MFEs work specifically and get to know the main advantages of using them: team scalability, reusability and technology agnoticism.

Micro-front ends - called MFE for short - is not a new approach, nor is the only good one that developers and teams should use in order to create maintainable and scalable front-end applications. However, it is a way of work that can bring benefits to an organization, if used correctly, and if it is based on the needs of the projects.

MFE is a code for segment of an application. In addition, we have a micro-frontend framework that is responsible for managing the loading and unloading of micro-frontends, as well as any operations such as I/O (input/output), routing between the micro-frontends, global configurations and so on.

Let´s dive a bit into one of the most widely used approaches nowadays - Single-page applications, also known as SPAs. SPAs mean that the whole source code is loaded and then APIs and databases are used to connect to and then render content on the client-side.

An example structure of such an application would look something like this:


                          

If you look at the Back-end and DevOps part - you can see that they usually have structure that allows them to scale independently with strong boundaries on what they are delivering and then become absolutely autonomous when delivering and deploying their services.

      

When a company grows and its teams expand as well, they have to identify the areas that have to be cultivated in their organization. Usually, a team will take a monolith structure and split it into multiple micro-services and create a dedicated infrastructure.

But what do you do on the front-end side? It becomes very challenging to scale and maintain when you have multiple distributed teams working on the same codebase. This creates communication issues for managing different parts of the UI, interdependency between teams, etc.

Scaling our applications with Micro-frontends

As explained earlier - we take our monolith structure and break it into multiple APIs driven by multiple containers, which creates our infrastructure that is dedicated for certain micro-services. The same can be done for the micro-frontend.

Introducing MFEs bring autonomy within a business domain, responsibility of the teams for each domain (or sub-domain) they are working on, and last but not least, capability of introducing improvements and new features to certain MFE without affecting the entire structure and application.

Main benefits of micro-frontends

Team scalability which means that each team can be set up autonomously and can invent, organize, initiate and deliver without affecting other parts of the application. In this way, a team responsible for one part of the application can deploy independently from another team.

It´s good to know that you should avoid "horizontal" teams that are responsible for the same area in two or more different MFEs. Instead, a more suitable and sustainable approach is vertical. A vertical approach means that a team that works on one micro-frontend is absolutely cross-functional and has all the knowledge to work self-reliantly.

The MFE approach also allows, for example, the platform team, which is responsible for the structure that wraps the micro-frontends, to be more focused on long-term goals, performances, routing, etc.

          

The micro-frontend teams are more customer-centric based. They are interested more in how to convert and engage the customer better, and improve the subdomain that they are working on.

The second benefit and advantage of this approach is reusability. We can take any part, such as the navigation component, and reuse it whenever we want to as long as we follow the MFE standard. The same is valid for other parts as well. A good way to have reusable components all across the different micro-frontends is to create a shared component library that you can maintain separately and use whenever needed. It will be very helpful for the teams if this is planned at the early stage and all pros and cons are taken into consideration before deciding on the best approach.

The third advantage of the MFE approach is the technology agnosticism. We can have our structure written in Vanilla JS, and any of our micro-frontends written in React,Vue.js, or whatever is suitable, as long as we maintain the standard of the MFEs. 

To summarize the benefits; with micro-frontends we can achieve better team scalability, reusability of the code, self-reliant teams and independent deployments as well as technology agnosticism.

It´s important to note that MFEs bring complexity and complexity is not always a desirable feature.

There is a lot more to be reviewed regarding our topic, and people have long started to recognize different approaches that work best for their cases and products depending on the infrastructure of the organization.

Are you interested in more information? Connect with us and learn how you can make use of MFEs.

***

Radoslav Radoychev is Head of Front End Development in our Gabrovo & Veliko Tarnovo offices, Bulgaria.