Micro Frontends Architecture for Dummies

8 min readJul 8, 2019

Micro frontend is a modern architecture style which is biased by Microservices Architecture for backend system. It is an extension of Microservices to the frontend world. It leverage all the benefits of Microservices to the frontend part of the Software. The term Micro Frontends first came up in ThoughtWorks Technology Radar at the end of 2016. The current trend is to build a Single Page Application (SPA), which sits on top of a micro service architecture.

The motivation behind the Micro Frontends Architecture is visualize the Web App with composition of small Ligos (feature) and constitute an App which work seamlessly. However, this idea is not new, in the past it went by the name of Frontend Integration for Verticalised Systems or Self-contained Systems. But Micro Frontends is clearly a more friendly and less bulky term.

Evolution of Software Architecture

Software is mainly consisted of three layers:

Frontend Layer: The frontend can be in the form of user-interface which means it can a Mobile App, a Web App or it can be in other forms as well. It can be anything which help the end-user to interact with the system.
Backend Layer: The backend is the part of a system where the business logic reside. It is a core of the software.
Storage Layer: Storage layer is the part of software where all the application related data is being stored. It is the place from where application fetches the data.

Earlier the frontend and backend software components would be bundled into one application package which these days we call the Monolith Style of Architecture. And the code for such software would be in one repository and that one code repository would contain folders dedicated to the frontend and the backend parts of the application, but it would be one large solution that contained both the UI and the business logic and and this entire code base would be maintained by one large team.

It means, if you want to make any change in such a big code base then we have to take the changes very seriously along with deliberate deployment and testing because of the impact of breaking anything else that’s unrelated to the change.

The software industry soon realized a benefit in splitting frontend and backend code bases but simultaneously we ended up with the team that is specialized in frontend and a separate team for backend and this was mainly because people realized that the frontend code and the skillsets required to maintain it had become very specialist, and if you wanted good-looking software, you needed to treat the frontend part of your application as a specialist area that required a team with the dedicated skills and so for backend as well. But the main reason for splitting the frontend and backend was the complexities in maintaining the software application. But things got tremendously improved by splitting the frontend and backend, now software backend is exposed as APIs which can communicate/interacted by multiple frontends such as mobile, web app via API Gateways or BFF.

Eventually backend started suffering from scalability issues because of increasing number of features (business logic). So as the business logic, functionality and data grew, so did the size of the backend systems to support this business logic data and functionality, and at the same time the backend teams also had to grow in size in order to maintain these large backend systems. And when we started to experience that one backend system in the form of services and APIs had to serve multiple different types of frontends in the form of web applications and mobile applications, something had to be done with the backend to address the scaling issues. And the solution for backend was to use microservices architecture to split the large monolith backend applications into smaller services and APIs, each with a clear scope and responsibilities and each smaller backend system i. e. each microservice would have a dedicated team that specialized within that service’s responsibility in terms of domain knowledge instead of large backend team responsible to maintain big code base.

Now the industry deployed small teams, each responsible for a single API and its code base which seems to be much more maintainable. Microservices architecture resolved almost all the backend scaling issues but now we started facing the scaling issues with frontend as well. Here Microservices architecture appeared as flare to solve the frontend scaling issues. We can visualize Microservices design principle applied on our monolith frontend to solve the scaling issue as it happened for backend in the course of time.

Microservices

In this blog, I don’t want to discuss in details about Microservices architecture but will discuss in brief for those who are not very well acquainted with the concepts of Microservices architecture.

Microservices are all about small components in the form of Services and APIs which satisfy below properties:

High Cohesion: It tells us that each Service (API) has one single responsibility and one single focus which means it does one thing and it does it well. And what if our frontend application was also made up of smaller components, each with a single focus ?
Autonomous: It basically means each microservice can be independently changed/deployed without affecting anything else. What if the same was also true for our frontend ?
Domain-centric: It means that a single microservices represents a specific business domain or business function within the organization. What if this was also true for our frontend, where our frontend is made up of smaller components, each one relating to a different specific area within the business ?
Resilient: When there is a failure, the system is resilient to the failure, it tries to fail fast, it tries to embrace the failure by defaulting or degrading the functionality. What if the same advantage we can leverage in our frontend as well ? i.e. if there is a failure for specific part of our frontend gets invisible to the end-user.
Observable: This basically means by using centralized logging and centralized monitoring, we can see what each one of our microservices is doing and we can also monitor the health of that microservice. And again What if we had the same advantage at our frontend layer where each micro frontend is transparent in terms of what the user is doing and in terms of what the health is of that micro frontend application.
Automation: It tells us that each microservices should be automated in terms of test and deployment and what if we apply the same for our frontend application.

Hopefully from this we can see the advantages our backend systems have enjoyed since microservices architecture style has come into fashion, and also at the same time how these advantages should also be advantages at the frontend level.

Issues with Monolith Frontends

Scaling Issues: The application will face scaling issues in terms of frontend application as well as in terms of frontend teams as well. The codebase will gradually become too large, intertwined, harder to maintain and making a small change will become quite cumbersome.
Communication: Communication among the team become slow because when one change is required, the product owner has to talk to a larger frontend team and coordinate the communication between the frontend team and the backend teams which maintain all the APIs and services which power the frontend features.
Code and Testing Complexity: Monolith frontends inherently bring the code and testing complexities and this is because all the features are intertwined, and changing one feature might result in a negative impact on another feature within your frontend application, therefore overall there is an increased risk of managing this type of monolith frontend. And this increased risk will result in slowed continuous delivery because there will be nervousness around releasing anything because of the risk of breaking something in Production.

The only real advantage of having a monolith frontend is that you still only have one single code base, so all the code for all your features is in one pot, and that might ultimately mean that the frontend application is easier to set up for testing and development environments.

Law of Diminishing Returns

By above understanding we can visualize the scenario when the Monolith frontend application grows in size of codebase as well as team:

As the size of frontend application increases, the dependencies on third-party internal external systems and libraries also increases.
More resources are needed to maintain such a large codebase and consistent coordination required to make any change in such large codebase by huge team which will make the ability to change the application quite slower.
Technology frameworks used within the monolithic frontend also become older and more stale and it is not easy game to change them all or sometimes it is near about re-writing the application.
Since the technology becomes stale there will be crises of resource to work on them.
The innovations in the application become stagnate.

Micro Frontends

Micro frontends architecture aims to solve all the problems associated with a monolithic frontend application and it does this in a similar fashion to the way microservices architecture solves all the problems we had with backend systems.

This is the reason sometimes micro frontends is referred to as an extension of microservices to the frontend or even sometimes it’s known as a microservices websites instead of micro frontends. Basically we are trying to make our software completely vertically sliced end-to-end and this vertical slicing means that our frontend micro frontends are in line with the supporting backend microservices.

For example within our web app you might have an advert section. That advert section is actually an end-to-end feature in the form of a micro frontend, which is the advert section and in the background it has a microservice or a number of microservices which support that micro frontend. And this entire feature is owned by one team which supports, maintains and develops this feature end-to-end including the micro frontend application as well.

Like this we are inheriting some of the feature of Microservices (by doing vertical slicing). And also if we get any performance issue in any of the feature or if we want to scale up/out any particular feature then we can simply focus of scalability aspects of that particular feature only.

And also at teams level we are enriching the domain knowledge as they are one end-to-end feature.

One of the key aspects of the micro frontend architecture is to give the illusion of one unified application and not to give away the fact that your one unified application is actually made up of multiple micro frontends. And one of the most common scenarios where you’re achieving this is — to use a base app which is basically a shell which houses all your micro frontend applications.

In above example which shows how micro frontend applications come together to form one unified application. Our single unified application is actually made up of multiple applications which are owned by different teams. These are micro frontend applications, within the shell, within the base app, within the browser, these applications interact with each other, giving you the illusion of one functioning application which is consistent and coherent.