The Story Behind the Micro-frontend Architecture

Over the past couple of years, we’ve seen a staggering increase in interest in microservices-based architecture. 

But to understand this trend, you first need to understand some of the issues that development teams struggled with over the years:

‍

• Extreme inter-team dependency
• Goal misalignment and miscommunication
• Software maintenance difficulties
• Low levels of modularity

And these are just some of the top challenges recorded as development teams started scaling simultaneously with the applications they were building. 

‍

Here’s the deal: even if the initial plan was to build a Single Page Application (SPA), it’s critical to think beyond its primary elements and consider what it might become. Because, as they grow and get upgrades, web apps increase in the number of features they offer and as such become too big for one development team to maintain. 

‍

To further support app development and contribute to the improvement of its functionality, it is necessary to employ multiple development teams, each with a mission of their own; each with an environment in which they can focus on their objectives without worrying that their work will clash with another team; an environment where they can build end-to-end solutions - from a database to a user-friendly interface. 

‍

And that’s precisely what you get from micro-frontend. 

‍

‍

What is micro-frontend architecture?

‍

Micro-frontend refers to the front-end architecture used by multiple web development teams to build modern web application features independently. It was designed to simplify the Frontend Monolith approach, and instead break one large app into smaller independent modules. 

‍

‍

When should you use micro-frontend architecture?

‍

Micro-frontend architecture is dubbed the best alternative for the Monolith approach. It represents one of the most viable solutions for building scalable web applications because, as they grow, so does your development team.

Once SPAs scale, the Monolith system prevents developers from making even the smallest of changes without blocking each other out. Micro-frontend removes this conflict, improves productivity, and maximizes results. As such, it enables the creation of feature-rich and powerful browser applications that tend to scale over time and become more and more difficult to maintain.

‍

The benefits of using micro-frontend

‍

Micro-frontend architecture continues to grow in popularity as we speak, with some of the greatest advantages including:

‍

• Application and web development team scalability. Multiple teams can work independently and upgrade stacks without having to coordinate simultaneously with other teams. 
• Development and deployment independence. All teams work 100% within their particular areas, that is, each micro-frontend team works on the functionality of their respective micro-frontend. 
• Code isolation. Even within the same framework, which means that developers don’t have to rely on a shared state.
• Tech independence. Development teams can use different technologies simultaneously, mix them together without worrying about their deployment, and create a single, unique front-end. 
• The creation of team prefixes. Each team can name their events, CSS, cookies, etc. to clarify ownership of those elements and avoid collisions with other teams’ work. 
• Code reusability. A component can be built and deployed in one place and then reused by a different development team.
• High deployment and development speeds.
• Simplified testing. Plus, if anything goes wrong, developers can quickly roll back to a previous version, which provides more room for innovation.
• The steep learning curve. Young developers and new team members can jump on a new project quickly, as opposed to Monolith systems where they are introduced to thousands of lines of code.
• Freedom to innovate. Due to modularity, the addition of new features is possible without interrupting primary services.

‍

The cons of micro-frontend

‍

The above all sounds amazing, but micro-frontend is not without its drawbacks:

‍

• Management of graphical assets. To appear uniform from users’ point of view, images and styles used in the app cannot be managed 100 percent independently.
• Getting the full picture. With each development team designing, testing, and deploying separately from other teams, it is difficult to keep track of all micro-frontend tasks. With all activities happening independently, deployment becomes riskier and testing becomes more difficult. 
• Standardization. To deliver a high-quality UX experience, all development teams need to be working off the same standards, and not have one team diminishing or improving the quality of the code. 
• Micro-frontend maturity. Though the concept has been around for some time, it has been introduced as a part of webpack 5 quite recently. For this reason, more work needs to be done to create a pattern that can be used among several teams who are using the webpack.

Why combine micro-frontend with ReactJS

‍

As we already pointed out in one of our previous posts, React is among the most widely used JavaScript frameworks. Giants like Netflix, Airbnb, Facebook, Uber, and others are leveraging the benefits of ReactJS to build SPAs, data-heavy, and interactive dashboards. 

‍

But what really attracts developers to this particular framework is the component-based architecture, where each property is developed with its own login and can be manipulated without affecting the DOM. 

‍

When combined with micro-frontend solutions, React turns into an attractive solution for the development of scaling applications. To fully utilize the benefits of this architecture, React developers chose to rely on dependable frameworks that they know will help teams grow without stepping on each other’s toes. The three most commonly used ones include:

‍

• Single-spa, a JS framework that enables lazy loading, allows you to split code by functionality, and combines multiple small apps so that dev teams can work independently. 
• Frint.js, a modular, extensible, and component-based framework ideal for reactive apps built from scratch.
• Piral.io, a micro-frontend framework that helps integrate React components in the form of a plugin model.

Sure, there are more. The fact is that microservices have been around only for a couple of years which means that we are yet to explore the field and develop solutions that will allow us to fully envision the benefits of the micro-frontend architecture. 

‍

What are your plans for the next project? How big do you expect it to get and are you going to need a team to cope with the (not-so-) microtasks?