Microfront-end: what they are and why are they used

In the world of web development, the technique of microfront-end development is becoming increasingly popular. This is one of the most innovative concepts in the front-end world since the introduction of Single Page Applications (SPA). However, it essentially takes up and re-adopts techniques that had already been used but never defined in an organic manner and now partly forgotten.

The basic idea is borrowed from the microservices technique, already widely used in the world of backend development, in which an application is nothing more than a set of services. Such services have the characteristic of being not at all or weakly bundled (i.e. without or with a minimal amount of interaction points between them, such as a database or a cache), and of the finest possible granularity, i.e. the functionality must be minimal. Amazon establishes the informal rule that, in order not to exceed the number of members of the development team of a microservice, it can be fed with at most two (American, therefore large) pizzas.

The advantages of this approach are evident:

• microservices development teams are as independent as possible and do not hinder the work of other teams with their own problems or delays;
• the crash of a single microservice does not compromise the stability of the other microservices;
• as a result, the stability of the gateway itself is enhanced;
• the application’s attack surface is fragmented between the various microservices, isolating the problem of any malicious hacks.

Front-end development today

Front-end development, on the other hand, has seen an evolution of development practices in the opposite direction. The advent of Single Page Applications – whether developed in React, Angular or any modern framework – meant that web applications were managed entirely by a single monolith application, with a high level of coupling between functionalities. This has in turn led to advantages:

• easy to create a homogeneous look&feel of the application;
• management of browser routes as part of the application state;
• one-off download of application assets;
• data transfer reduced to status update only.

However, front-end development has not always resulted in monolithic applications. There was a time when web pages and applications usually consisted of a main skeleton and a set of isolated, often unevenly sided widgets. But this is where the concept of microfront-end starts.

Basic ideas

The basic idea of a microfront-end architecture is to divide the overall interface into interactive sub-functions that are as independent as possible.

Once the sub-interfaces have been identified, each of them – which will eventually become a microfront-end – is developed in parallel between different teams, as well as the management and coordination layer of the various microfront-ends. This is an approach that follows that of the microservice architecture, where the orchestrator layer acts as the back-end gateway.

Each microfront-end will therefore consist of a small application representing a single feature, loaded and displayed by the orchestrator layer together with the others, and independent of them. The implementation will use common frontend development methods, based on a modern framework (Angular, Vue, React, …) and libraries for data manipulation and views.

The immediate advantages are as follows, similar to those already known for microservices:

• greater freedom for teams to choose their own technology stack;
• less effort needed for coordination between teams and more time spent on product development and care;
• developments of the individual parts more quickly because they are independent of each other.

After all, the compromises to be made when using microfronts are also immediately apparent:

• each microfront-end will have as dependencies its own libraries and frameworks required for operation: the user may therefore have to download, analyse and run several versions of the same package;
• UI and UX design guidelines must be clear and well defined beforehand, otherwise there is a risk of having a cacophony of user experiences;
• the orchestrator layer must have a clear and agreed interface with the development teams.

Carrying out the insulation

One of the key points of the microfront-end concept, like that of microservices, is the decoupling between them. This means that each part of the interface must affect its own branch of the page’s DOM, will have styles that only act on it, and will have to define a namespace in the global variable space that it must not leave.

The microfront-ends are contained and communicate with the orchestrator layer via a well-defined interface. The creation of global events, such as showing a dialogue box, is delegated to the orchestrator by sending messages with agreed payloads.

The easiest way to achieve this is to use elements <iframe>, but these pay the price of being heavy in terms of loading and memory usage. They also confine the microfront-end to a well-defined visual area, with no way of getting out of it without the orchestrator layer.

Another good approach is to package the microfront-end in a custom element, possibly with style encapsulation. A framework like Angular supports this procedure natively.

Custom Elements, with their shadow Dom and encapsulated style, offer the level of insulation needed for a microfront-end architecture.

In other cases, the packaged version of microfront-ends will have to be kept isolated, taking care of any possible conflicting aspects between the various parts.

Microfront-end: why yes

At this point, it is clear that a microfront-end architecture is aimed at the developer experience (DX), in order to optimise the frequency of updates and the isolation of problems, partly by sacrificing initial start-up time and memory and processor effort.

This is an approach that ideally spans large-scale web applications used in the business environment, but does not exclude other widely used web platforms where the “weight” of the purely application part is overridden by other assets (e.g. multimedia content use).

Microfront-end: why not

As mentioned, the use of a microfront-end architecture involves compromises in terms of resource commitment. This can be mitigated by a system infrastructure that enables the sharing of common packages and libraries, through the use of a Content Delivery Network (CDN) and more modern transfer protocols such as HTTP/2 and the forthcoming HTTP/3. It must be remembered that allowing teams more freedom in choosing their technology stack does not mean giving them carte blanche: it is perfectly legitimate to restrict the scope of choices to certain common frameworks and libraries, in order to create homogeneous code bases that are more manageable through code review.

The use of a CDN makes it possible to minimise the resources to be downloaded if they are shared between the various microfronts and the orchestrator (which in turn is an application). Some microfront-ends may still carry application-specific packages.

However, even with these precautions, the use of microfront-ends may not be the best solution. For example:

• if the scope of the project is manageable by a single team;
• whether it is possible to have a good parallelisation of the developments of the different parts of the application between the different teams;
• if, due to the target audience and connectivity, one should aim for a minimal use of client resources.

The best choice

It must first be made clear that microfront-ends are not a technique for doing new things, but only for approaching projects with a new approach. In fact, the same results can be achieved with a monolithic development, but this requires coordination, teamwork and communication skills between teams, as well as the dissemination of technical skills gained from many years of experience.

When even one of these points is lacking, there are normal problems of coordination between teams, which the microfront-end approach tries to circumvent. For example, this methodology may be valid in the case of features developed by several teams of external suppliers, who may not always have optimal communication with each other.

Similar development choices have always been made, but without a formal approach and precise definition of the method used. As a result, the various development issues listed above had not yet been addressed.

Today, the definition of the microfront-end concept helps to focus attention on precisely these methodological aspects.