The Micro Frontend style of architecture design do for the frontend of an application what microservices do for the backend, breaking monolithic structures into smaller components that can then be assembled on a single page.

From a technological perspective, where micro-service architecture (MSA[1]) has claimed its space by enabling the deconstruction of backend artifacts, many wonder whether it is possible to adopt such an approach to designing and developing frontends as well.

In this article, starting with a bit of history, we will focus on the challenge that micro frontend architectures wish to address and overcome. We assess the state-of-the-art and try to figure out the possible evolutions in the near future.

We the conclude this article explaining why micro frontends are a worthwhile pursuit, and the approach we currently embrace in supporting our clients who, driven by innovation, are already adopting this paradigm.

1  A bit of history

Back in the day, any frontend was a monolith. All functionalities, be it server-side or client-side, were placed inside the same software artifact. Specifically, backend and frontend logics where strongly coupled with a graphic rendering of components on the server side.

The first step towards the micro frontends philosophy started arrived with the layer-based approach; these “layers” helped unbundle the graphic components from the server-side. From that moment onwards, software artifacts split to more granular levels and the concept of Single Page Application (SPA) emerged.

The term Micro Frontend first appeared in literature towards the end of 2016 changing both the name and the goal of micro-service architecture. The idea is to find a way to break down (or deconstruct) the frontend into various self-consistent, functional components (or modules) defined as micro, with the objective of overcoming one of the biggest problems in the development and management of a single codebase.

A paradigm shift happened in the following two years, when an approach called “Backend for Frontend” (BFF) emerged. The backend is broken down into artifacts (logical or material); this provides a complete set of functionalities required by the client. This permits to the teams can work on a subset of functionalities in parallel. The same approach can be applied to the monolithic client (frontend) as it is possible to split the frontend in modules with a breakdown based on page and/or functionality, each part is completely owned by a single team.

To overcome the limits of monolithic client, the idea of Web Component begins. The idea is to take advantage of the W3C standard called Custom Elements which enables adoption of the browser with DOM element written in Javascript. The idea is to create elements not only for informative representation, but also to use them for broader scope in the micro-frontend context.

Nowadays, several initiatives have been set in motion in the use of micro-frontend, specifically thanks to the use of the Web Component. IKEA uses micro frontend on their online store, instead Spotify uses them in their desktop application. Zalando is the owner of the Project Mosaic, an initiative that gathers a set of services and libraries useful for micro frontend.

2 Weaknesses of traditional approach

In the context of development, maintenance or migration of a software, the challenges we face are related to time-to-market, and the maintainability of the artifacts. On one hand, for the backend, the problem is mitigated with the introduction of micro-services architectural style. On the other hand, for the frontend the problems to be addressed are mainly the following:

1. It is possible to split an application into modules, but the codebase remains the same, so the teams working on frontend artifacts, at the same time, must spend some time coordinating.
2. Compile times increase in proportion to the lines of code. Even optimizing, each change or integration requires an entire artifact recompile.
3. When intervening on a module to modify the application, the entire artifact must be redeployed. The change is never really isolated from the rest of the application with a relevant risk of regressions.
4. Frontend deployment, both for changes on a module or refactoring of the entire application, requires management of the entire deployment cycle with resulting disruption on the entire application.

In fact, we have partially nullified the positive effect introduced by micro-services, in terms of Time to Delivery (TTD) and Time to Market (TTM) (when the frontend remains a monolith).

3 Technology challenges

Based on the above, it is clearly useful to separate artifacts (in the frontend as well). Let us see the main challenges to face on frontend components.

Once the independent and autonomous modules have been identified and the micro app defined, it is essential to have a container (shell application) able to group, establish communication between and harmonize the various micro apps.

The elements provided by the micro apps are grafted into the shell application. The shell must be able to dynamically accommodate the micro apps, “composing” all the frontend. Each micro app can be upgraded independent of the shell.

The shell must ensure communication between components. A component interacts via events and properties. Therefore, it is the responsibility of the shell to orchestrate the hosted components in a consistent manner in relation to the declared interfaces.

In the end, one must worry about the application appearance. When the browser loads a component, in absence of directives, it assigns to the component a certain appearance. When implementing a Web Component, we must consider the following principles:

• the component must have a defined behavior, i.e. in the absence of directives it must present itself with default characteristics
• the component must never influence the behavior of the container
• the component must allow the container to customize its behavior

The considerations listed above lead to greater realization commitment, and care in terms of design.

4 Why choose Micro Frontends

Despite the challenges just described, let us look at the benefits of adopting this approach:

• micro apps are autonomous as each has a single responsibility
• micro apps can be developed independently, increasing parallelism
• subsets of the frontend can be released independently without impacting other parts of the system
• different Web Components can be developed in different technologies, which encourages both team rotation and adoption of more up-to-date frameworks without impacting existing components
• Web Components are reusable in any frontend other than those for which they were designed

5 Where we are today

The current landscape of support tools is quite diverse and rapidly evolving.

There are several frameworks born with the aim of creating Web Components, for example, the Polymer project that later became the LitElement project. OpenWC project is another, aiming to support the community in creating and sharing open-source Web Components where we find several libraries and components that embrace the initiative. Unfortunately, we are talking about projects that are divergent in their implementation.

Recently some libraries have come out on the market (single-spa, piral.io, frint.js) with the aim of providing useful tools to developers, in the form of development frameworks, for the implementation of applications based on the concept of the Micro Frontend.

There are also some marketplaces that aim to group Web Components in one place and make them available to the community. In some cases, the approach is strongly linked to a single product, see Vaadin, in others, web-components.org, you can find so many different elements. Since there are no guidelines or standards, even de-facto, it becomes complex to base an application on Web Components, lowering the investment.

6 A market view

ThoughtWorks, in 2019, tag micro frontend with ‘Adopt’ status in Technology Radar. In May 2020, it lists as one of the major benefits, the ability for teams to scale in distributed service delivery and manage them independently. They cite the article[2] (at martinfowler.com) as the main reference for this technique.

However, on ThoughtWorks, we find around the same time, October 2020, in ‘Hold’ status, the term micro frontend anarchy. Using this architecture as an excuse to mix a range of competing technologies, tools, or frameworks on a single page, leading to micro frontend anarchy is a worrying trend indeed. In fact, today, there is no established standard, neither from the community nor from players that can impose standard-de-facto on the market. There is definitely a lot of confusion: companies that advertise the pattern are appearing on the market; libraries are being released to support who approach developments following the methodology; frameworks are being proposed to support development with the main technologies used for frontend components.

Large multinational companies are approaching this paradigm for their online products. IKEA prefers to split a system vertically to create standalone systems with backend and frontend built by the same group of developers. The key to success is keeping teams small. Jeff Bezos calls this the “two-pizza rule”: if one team is too large to feed itself with two pizzas, the team is simply too large. Micro frontends have allowed DAZN to empower smaller teams that can work independently. HelloFresh solved the problems of managing its monolithic application by breaking it up, so each micro app has its own server and isolated development environment.

Probably, in the short term there will be a new framework that will address the resolution of the typical problems that are encountered with this choice, or some influential market player will approach the topic in a structured way that will result in a standard.

7 Why Bip

In Bip xTech, since mid-2020, we are adopting the micro frontend approach in the development of some enterprise solutions.

We started the adoption of this paradigm after intense market analysis and careful considerations on the right approach, first from an abstract point of view, then influenced by real delivery contexts. We always keep a close eye on market trends so that we can adapt to it and benefit from emerging techniques and new tools.

Since the production release of systems that benefit from this technique, we can say that the benefits are significant. From our internal estimations, we can say that we have reduced development efforts by 30% with savings in terms of time and costs. We can scale the delivery with workgroups because the functionalities are well delimited, and the code is autonomous and independent. The portions of the system are sufficiently simple and the quickness of the approach to each single component is greatly increased, the regressions, at each release step, are strongly decreased. The effort spent on testing has decreased by 30% and the operation time, following the reports received in AM (Application Maintenance), has practically halved. In the end, the adoption of micro frontends allows us to migrate legacy code incrementally without the need to deal with impactful reengineering in one fell swoop.

In conclusion, we remain vigilant as we wait for the turning point by focusing on contributing with our experience in the field.

---

If you are interested in learning more about our offer or would like to have a conversation with one of our experts, please send an email to [email protected] with “Micro Frontends” as subject, and you will be contacted promptly.

---

[1] https://www.bipxtech.com/introduction-to-microservices/

[2] https://martinfowler.com/articles/micro-frontends.html