Microfrontends Architecture

From a little before 2016 a type of architecture in the frontend, called MicroFrontend, was becoming popular. Today, we can find large international companies using it in their day to day. But what does it consist of? Is it really something new?

A reality of large companies is that on many occasions they end up developing applications and / or websites of a large size and complexity, which can take years to develop and a large number of people and development teams, which are often distributed by different countries.

Context

Previously, there were different approaches to be able to finalize the software, which was stable for a long period of time and which was also maintainable. For this, some of the solutions were to use Liferay or Oracle style portals, the beloved and feared Iframes or simply, use the browser tabs or develop it and then adapt as you could.

Además, con un público objetivo cada vez más global y más numeroso, provocando la evolución de las Arquitecturas backend, orientando su diseño a la escalabilidad, reutilización, flexibilidad y orientación a negocio. Hoy en día, la mayoría de las arquitecturas que nos encontraremos serán con microservicios. Un ejemplo de su evolución sería:

As you can see in the previous diagrams, in the last indicated phase, we could have a separate backend in smaller pieces. This would be, in part, to look for its scalability, maintenance, customer orientation, etc ... But if we look at the interface, it remains the same as in the previous step, where we have a large part attached.

In previous years, a step prior to microfontends, we could find component-oriented architectures. With the standardization of web components by browsers, we could achieve a great reuse of the used code and speed up the development process. Within this type of solution, one of the most widely used was Atomic's, where we divided the different components into atoms, molecules, organisms, templates and pages, according to the type of granularity they had. Used in many projects with Polymer.

If we compare it with the previous diagrams, we would have something similar to:

But as you can see, despite winning with reuse, when it comes to integration, we would continue talking about a single project. Although the rest of the projects, they would reuse those same components.

At this point, it is where we start talking about the Microfrontends, which we know today.

Microfrontends

When we talk about Microfrontends, we are talking about a type of architecture that has been around for a few years. Although it took Spain a few years to arrive, we could define it as an architecture oriented to small applications to later integrate them into a plant.

We can integrate this frontend architecture with different Backend architectures, to further optimize its results. A clear example that we can find in some companies is the joint use of the Backend For Frontend pattern with Microservices and Microfrontend. In addition, in many cases, we can find that the reusable component-oriented architecture, integrated with the microfrontend, continues to be used, achieving greater reuse of the code and functionalities.

If we are lucky enough to attend a technological event in Spain and / or international, we can see how some companies and / or technicians have been explaining different ways of using this type of architecture solution. Some examples would be:

Each of them uses a different approach to approach the Microfrontends.

General Options

If given certain needs, in the end we decide to implement this type of solution, we will have different alternatives, depending on the advantages we want to obtain. If we had to include the different solutions, you could classify them in:

• Mono repository
• Multi repository
• Meta repository
  

When we talk about mono repository, we are referring to those solutions, where in the end all the projects will be within the same repository. This may seem somewhat contradictory to the Microfrontends theory, where we were looking to generate independent projects to later integrate them. But in this case, what we will find will be a system of unique dependencies for all projects, and subfolders for each of the projects. An example of this solution would be the one given by Angular by default to generate sub applications internally.

On the other hand, in the multi repository we would have the projects in different repositories. This would involve more isolated projects and a separate dependency system for each project.

Finally, we would have the meta repository, which would be a strategy that would try to combine the previous two. We would have multiple repositories but additionally, we would have one where they would all be integrated.

Each of these systems has its advantages and disadvantages, and each would have different ways to mitigate its disadvantages. Some of these configurations can be adapted through a suitable continuous integration strategy or through specific git functionalities such as submodules.

Technical Options

To address each of the above solutions, there are different technical approaches. All of them could be classified into:

• Build-time Integration: created at application build time
• Server-side Integration: integrated in the page by the server while the user is browsing
• Client-side Integration: micro applications are downloaded and integrated through the browser

Reusable Components

Despite the fact that the reusable components, as its name indicates, are initially only for small options, small functionalities, etc ... in some cases, using the same technique, we can design and develop reusable micro applications. We can approach this solution from the same repository, integrating it into our project, or installing it as a third-party dependency. Also depending on the framework and / or rendering libraries that we use (angular, react, vuejs, svelte ...), we will have some options or others.

An example of this, if we also include the webcomponents in this case, would be:

• Vanilla webcomponent
• Angular library
• Lit-element
• Angular Elements
• Stenciljs
• Vuejs components
• Reacjs components
• NX Plugins

Iframes

This well-known option would only be applicable to multi-repository solutions. Where we would be indicating in each tag, the website that we would like to see.

Micro projects

One solution offered in some mono repositories is the integration of microprojects within. Some technologies such as Angular, NX, etc ... provide us with commands and an integrated routing system, which would facilitate both its creation and its testing and deployment.

Server Side Includes

In this option, we would have the different applications or only one, and the integration would be carried out from the server. So for our frontend application we would have to display two parts, one for visualization and the other to manage all tasks on the server. Depending on the technology we use, it would facilitate the work Angular Universal (for angular), Next (for React), Nuxt (for Vuejs) and Sapper (for Svelte).

CDN

Through the use of CDNs, when the user enters a section, the static content of an AWS bucket, Akamai and / or any other service that provides this functionality is downloaded.

Server Side Integration

Through the configuration of Ngnix, Apache or the server that we are using, we can configure that when the desired micro application is loaded in a certain direction.

In addition to all the options discussed, there are others.

Summary

In the event that we want to venture into this type of architecture for our projects and / or company, we must first analyze our needs, to choose both the appropriate strategy and the most optimal technologies. In addition to being able to use several of these systems at the same time, in order to cover both legacy and modern projects.

As Darwin said: "The species that survive are not the strongest or the most intelligent, but those that adapt best to change". The same will happen to our applications.