Scalability of frontend applications with a micro-frontends architecture

Good day to everyone!

In this article, I would like to touch on the scalability topic during the transition period from startup to mature company, share my mind, and explain a few techniques we use in the organization I work with.

Many different articles explain and cover the scalability topic, but I would like to clarify what I mean by scalability in this article:

Scalability is the ability of the frontend system to deliver value to end-users in a faster, reliable, and more straightforward manner on each live circle of the system

There are many principles a scalable application should share, but I would highlight one of the most important: separation of concerns and architecture design.

In this article, I will operate terms based on the team topologies concept and will divide teams by functionality into four groups: stream-aligned team, enablement team, complicated subsystem team, and platform team.

The era of startup companies

We are living in the epoch of startup companies. Every day a new startup company is opened or closed, and entrepreneurs are looking for new opportunities to bring a new business model to our lives. We could observe growing and failing individuals and companies.

From the technological point of view at this stage of the company’s life circle, the technologies in the organization are small enough, easy to maintain, easy to grow, and easy to bring new value to the business. Making mistakes at this stage is not critical and could be easily fixed. Of course, this does not mean that the initial architecture is not important and business needs very good specialists who could make architectural decisions in the early stages. There is no sense to use a multi-team model in the organization. At this stage, one or two development teams (5–10 team members each) are more than enough. I would mark it as an organizational mistake having more teams at this stage.

At this company’s age, the best approach from a frontend point of view is using one small monolithic application. It has many benefits:

• keeping code compact, and easy to work with
• monolithic architecture is natural and easy enough to implement
• continuous integration and deployment are not overloaded

The age of giants

We will not talk too much about IT giants and mature companies. We just need to mention that a mature company already has a well-working business, working processes, well-established in its industry, and has multiple working teams who concentrate on its functions.

At this stage, one of the key factors is deligating functional work into specialized teams that focus on it and do not allow to any particular team to cover multiple functions in it.

Transition a startup company to a mature company

In time, a startup company is reaching boiling point when frontend applications started to be not flexible enough to keep the same velocity as the business has.

Delivering new functions and covering business needs is delayed in each delivery period. Empty promises to businesses from tech teams who cannot recognize yet that circumstances are changed. Teams still could think that they can deliver a new feature on a certain date, but fail again and again.

The organization could increase the number of teams or engineers to cover the most important needs. Unfortunately, in many cases including more people in tech teams brings no value. The processes should be changed.

The most common symptoms that the system is not scalable anymore are:

• difficulties in the system maintenance
• fragile system when a developer does not know that could be broken during particular changes which lead to often critical incidents
• overloaded continuous integration / continuous deployment process when engineers should stay in line to deliver their features or bug fixes
• impossibility to switch technological stacks from one to another without the entire system change
• difficulties with keeping an application up to date and updating versions
• confusing codebase when multiple teams are delivering into the same codebase
• having abandoned code when no team has responsibility for its maintenance and improvements
• no clear responsibility between teams
• multi-functional teams, e.i. a stream-align team is doing enablement functions or platform job

Making technological mistakes in the transition period is very and very costly. At this stage, all mistakes, that came from the startup stage, are getting visible very well.

To allow the business processes to continue growing the tech leadership in the organization should adjust their current state. One of the popular solutions is migration from a monolithic architecture to micro-services (in the case of backend technologies) or micro-frontends (in the case of frontend technologies) architecture.

Since we are talking about frontend technologies in this article I would continue talking about micro-frontends, not micro-services. Also, I would like to drop the question is the micro-frontend architecture is good or bad because there are many articles and discussions, as well as which micro-frontend approach is worse or better.

Instead, I would like to consider the micro-frontend architecture from the scalability point of view and how it could unblock organizations in the transition state who started to build the multi-team model.

Micro-frontends architecture

Benefits of the micro-frontend architecture in multi-team model

MicroFrontends an architectural style (pattern) where independently deliverable frontend applications are composed into a greater whole. (microfrontends.com)
It is a technique that impacts the organization, providing decoupling between teams, avoiding too much centralization and, that is most important, empowering the teams on taking local decisions and do not depend on other teams.

Once an organization could find the symptoms of the not scalable system we described earlier, engineers could decide to transform the system from monolithic architecture to micro-frontend architecture. At the same time it could bring the next benefits to the company:

Code organization

The micro-frontend architecture allows teams to split one monolithic application codebase into small pieces of code. The source code for each individual micro-frontend will be much smaller and focus on one small part of the application. The edges which part of the application should be decoupled into a micro-frontend should be decided by the engineering team. It could be big parts like pages or small parts like elements. New code organization allows to new developers spend less time learning the codebase and start to contribute to the code in a short period.

Teams independence

A micro-frontend codebase should be isolated and will help stream-aligned teams choose their working strategy and processes. Each team has entire ownership of a vertical slice of the application and can specialize in their domain. They can stop to worry about interference between teams and reduce the need for coordination between them. Micro-frontends let structure your application follow the structure of your teams based on Conway’s law

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

- Melvin E. Conway

The use case example:

If a team wants to try new technology (another state manager, a new testing library, etc.) in the monolith, the decision should be aligned between all teams who are working with the application. It is time-consuming, and eventually, it could be not accepted by some teams. If the team is independent, the team’s engineers can decide what they are going to use. This decision is not touching other teams at all.

Release independence

Taking the same approach as microservices, the micro-frontend takes responsibility for its deployment. It gives the ability to the stream-aligned teams to release parts of the application independently. Rather than redeploying the entire application, each team can just deploy small pieces of it. It can empower teams to release when they need to, without needing to coordinate with other teams or fit into a company-wide release cycle. In case of troubles with the last deployments, it could be easily rollback without affecting the work of other teams. Splitting the codebase into small pieces gives the smaller time to deploy the micro-frontend.

Domain-Driven Architecture

One of the reasons for investing in micro-frontends is allowing vertical domain ownership. Moving from a monolith architecture that is owned by the entire company to micro-services that are owned by multiple teams, helped companies to scale the development among different teams and promote ownership of the backend. Each stream-aligned team owns a component end to end, vertically.

Reducing the surface of testing coverage

A small amount of code is easier to cover with tests than a large application. It leads to better testing coverage among the entire system because all small parts of code will be covered by tests.

Possibility to use different technologies and frameworks

One of the advantages of micro-frontends is not to be depending on chosen technologies and frameworks. It is much easier to find a dedicated team to work on the micro-frontend. It allows replacing not appropriate technologies, and frameworks with other ones as well as testing new technologies with small risks for business.

Basic principles of the micro-frontend architecture

I would cover the most important principles the micro-frontend architecture should follow to keep the system scalable. To do that we should introduce two terms:

• orchestrator is the parent application that orchestrates with all micro-frontends. In an ideal case, it contains no logic or business functions in it but only acts as an operator
• child micro-frontend is a domain-driven application that covers any particular part of the application

It does not matter which micro-frontend approach a tech team is decided to use, to keep the system scalable it is very important to follow the next inflexible requirements:

Inflexible requirements between children and orchestrator

• Almost zero coupling between orchestrator and children's apps
• Orchestrator should NOT know how the child micro-frontend is implemented. If the child’s implementation is changed but provides the same interface, nothing should be broken
• Children's micro-frontends must provide a unified interface to be included in the orchestrator
• All essential communications between children and orchestrators are done with callbacks or simple events
• The orchestrator should be able to decide to always use the latest version of a child or specify a specific version

Inflexible requirements between children's micro-frontends

• Zero coupling between children's micro-frontends. Each child should NOT know about other microfrontends and must be able to work in isolation
• No imports from one microfrontend into another
• No shared state management tools (Vuex, Redux)
• Shared libraries between children are possible
• All CSS code must be scoped to exclude overriding style properties

Micro-frontends architecture maintenance

Deciding to move into micro-frontend architecture is not the end of the transition journey. This will be painful and dangerous but in the same way an interesting and cognitive process. Many pitfalls will wait for the engineering team in this way.

One of those issues will be the maintenance of the entire micro-frontends architecture. In time, the system could count tens or hundreds of micro-frontends, and the engineering team will get a new challenge — how to maintain all those micro-frontends.

New micro-frontends introduction

This is the first problem the engineering team meets after the migration to the micro-frontend architecture. How to scaffold a new micro-frontend without additional complexity? Which team is responsible for the creation of new micro-frontends? Which standards should a micro-frontend follow?

Those and many other questions must be resolved by the engineering team to keep the system scalable and easy to maintain. Otherwise, the system will be very messy in a very short period.

We should get the solution when each new micro-frontend will be created very fast and with a very similar setup to keep consistency between all micro-frontends. The word “conveyor” comes to my mind.

There are multiple ways how to reach this. I would like to share one idea of how it could be reached: the tool which can take a template and create a new microfrontend in a few minutes. This could be a ready-to-use solution such the cookiecutter or another similar tool.

Synchronizing the existing micro-frontends

Creating a new micro-frontend is the only first step. In time, it will be many micro-frontends that should be synchronized with your basic template. It could be different reasons why we need it: removing vulnerabilities, updating the configuration, updating versions of other packages, etc.

Unfortunately, cookiecutter does not allow you to synchronize existing projects with templates. To solve this issue, in my organization we developed our solution which can scaffold and keep up to date or existing micro-frontends.

During the writing of Prove of Concept project, I created my project (mucli), based on the similar principles we followed in our organization. The project takes your repository on Github, looks for templates inside it, and installs a new project or syncs an existing one. The features it provides out of the box:

• Project installation and synchronization from templates repository. You could create your own templates repository and use mucli for installation and synchronization. Your templates repository is fully independent and maintained by you. The mucli package just works with your templates.
• User-friendly command-line interface with the ability to add custom user questions into each template.
• Dynamic values in files. It is possible to create custom files based on settings or user interactions.
• Prefixes system. You could mark your files with different prefixes to manipulate those files during the synchronization.
• Composable templates. It is possible to create a very flexible template from smaller modules.

Feel free to check and contribute to mucli project. I’m going deep dive into implementation details in the next articles.

Conclusions

In this article, I shared out thoughts and decisions we made during the transformation of our company from a startup state into a mature company.

If you’re interested in this article or other my articles feel free to follow me:

github: https://github.com/NovoManu

twitter: https://twitter.com/ManuSEngineer

That’s all folks.
See in the next article.