Table of Contents[Hide][Show]
The idea of microservices has gained a lot of attention recently, and many firms are using it to do away with large, monolithic backends.
Going the same route with the frontend is still a challenge for many businesses, even if this distributed manner of constructing the server-side of web apps is more or less reliable in terms of research and execution.
Due to its close dependency, the client-side monolith typically makes it difficult to integrate new features, adopt new technologies, and scale individual components.
These and other challenges have prompted frontend developers to investigate using microservices.
As a result, a brand-new architectural strategy known as micro frontend was developed for creating the front-end layer of websites and web-based applications.
The term was first used in 2016, and since then, it has garnered a lot of attention for a good cause.
This article will give a general understanding of what micro frontends are and the issues they address. it’s working, as well as pros and cons.
Introduction to micro front-end architecture
A contemporary method of front-end development called micro-frontend architecture divides a web application into small, independent parts.
To the end user, these parts appear to be one unit even if they were constructed independently and then put together.
With the difference that micro frontends pertain to the client side, not the server side, of online solutions, the rationale underlying them is identical to that of microservices.
Making sophisticated web-based products makes the most sense when using a micro frontend approach.
Micro frontends, as opposed to a more conventional front-end monolith, enable many teams to collaborate separately on various software projects.
Programmers can create web apps more quickly and with greater scalability and maintainability using this architectural design.
To put it simply, each micro frontend is just a piece of code for a distinct component of the web page.
These features are controlled by separate teams, each of which specializes in a certain industry or objective.
Monolithic vs Microservices vs Micro frontend architecture
Think of relocating. Will it be simpler for you to organize everything into a number of little, expertly labeled boxes and relocate each one individually or pack up the entire staff into one enormous box and transport it to a new location?
The obvious solution is there.
This analogy compares the two distinct web app architectures, monoliths and microservices (also known as micro frontends).
You might be able to recall the “good old days” when a complete application was created as a single, cohesive entity. Such a method is called a monolith, which is an old term for a large stone block.
This makes sense.
Monolithic systems have interdependent elements. Therefore, if you wish to modify something or add a new feature, it’s possible that the entire system may break.
Even though it is obsolete, it occasionally still exists. Yes, we are aware of your current expression.
The conceptual division of the codebase into two different components — frontend (client-side) and backend (server-side) — became unavoidable as new technologies developed and software products got more complicated.
The most popular method of operation is now the separation of concerns between the presentation layer that an end user interacts with and everything that takes place in the background.
It needs two software engineering teams, with the front-end team building the visual components and the back-end team building the web services, business logic, data access, integrations, etc.
However, despite this separation, this strategy still remains monolithic by nature.
The main change is that we now have two sizable blocks of code—the frontend and the backend—instead of one enormous application. Monolithic architectures don’t have to be terrible; they have a few benefits, including
- Simple and quick development for tiny applications with a single source codebase and a very simple design;
- Testing and debugging are very straightforward because all code is in one location, making it easier for a team to track a request’s flow and identify bugs;
- Early on in the development of an application, expenses are cheaper since neither infrastructure costs nor development costs are incurred until new features are added.
The drawbacks of this strategy are reflected in
- Restricted deployment flexibility – teams must wait if there are only a handful of them working on the project and new deployment is required every time you update the code;
- Adopting new technologies is challenging since doing so necessitates rewriting a significant portion, if not the entire project.
- When the number of developers increases, a system of code becomes closely connected, complicated, and difficult to manage and comprehend.
- Organizational issues – each team member must use the same version of libraries and report any changes if many teams are working on a monolithic project.
- Concerns with scalability – because the project’s components are interconnected, scaling them separately presents difficulties that result in significant downtime and higher expenditures.
- The project’s complex logic could be difficult for new team members to understand, especially if the engineers who originally worked on it are no longer employed.
The development of microservices and their close relatives, and micro frontends, addressed the primary problems with monolithic systems.
The architectural method known as microservices allows for the creation of many loosely linked and independently deployable smaller components, or services, that make up an application backend.
Every service has its own codebase, CI/CD pipelines, DevOps procedures, and processes for running them.
You can see that the monolithic backend team is divided into separate teams by looking at the image above.
Each focuses individually on a different aspect of the application (such as the product service, search service, and payment service).
Communication between the services occurs through established protocols known as APIs, such as the lightweight REST API protocol that uses synchronous request-reply patterns.
Another option is to use asynchronous communication using software like Kafka, which offers publish/subscribe communication structures and events.
Microservices integrate with the frontend via a backend for the frontend (BFF) service or an API Gateway through the network. BFF offers a customized API for each client, whereas API Gateways give a single point of access for a collection of microservices.
But even with autonomous backend components and all the advantages they provide, the frontend is still a monolith.
Therefore, this is where micro frontends are useful.
Micro frontends architecture
Similar to microservices, where loosely linked components are managed by several teams, the micro frontend architecture applies the concept to the browser.
These web application user interfaces follow this structure, which consists of somewhat autonomous components.
Teams are also created on client needs or use cases rather than particular expertise or technology.
Consequently, teams are involved in microservices and micro frontend projects.
- vertically sliced — as there are frontend developers, data experts, backend engineers, QA engineers, etc. working on the same project as well, they create their features from the user interface to databases; and
- cross-functional – each team member contributes their expertise to the group.
Teams can also select the tech stack that best suits their particular line of business.
One team can use React to program its fragment. Another team creates a new Angular version. Vue.js is one such example.
Micro frontends are used in conjunction with related microservices to address issues development teams typically have with monoliths. The strategy offers the following advantages.
- A greater degree of flexibility is possible since each micro frontend is self-contained and can be developed, tested, deployed, and upgraded separately. As a result, if one team is working on a feature and has pushed a bug fix, and another team has to add its own feature, they don’t need to wait for the first team to complete their task.
- Autonomous teams and systems: Each product team, and consequently each feature, can function with little dependence on others, which enables it to continue to work even when the nearby components are unavailable.
- Multiple, smaller codebases: Each of the micro frontends will have its own, more manageable, smaller codebase. Fewer people will focus on a specific UI component, simplify code reviews, and improve overall organization.
- Simple app scaling: Another benefit of micro frontends is the ability to scale each feature individually. As opposed to monoliths, where the entire program must be scaled each time a new feature is added, this makes the entire process more efficient in terms of both time and money.
How does micro frontend work?
As we’ve previously stated, teams are vertically organized inside the micro frontend architecture, which means they are separated by domain knowledge or purpose and are responsible from beginning to finish for a specific product.
It can have one or two backend microservices as well as a small frontend. In more detail, let’s examine this visual element’s characteristics, interactions with other UI components, and incorporation into the homepage.
A micro frontend can be
- a whole page (e.g., a product detail page) or
- sections of the page that can be used by other teams, such as the headers, footers, and search bars.
You can divide up a big website into several page kinds and give each type to a specific staff to work on.
However, several components frequently occur on numerous pages, such as headers, footers, suggestion blocks, etc. A suggestion block, for instance, can be included on a homepage, a product detail page, or even the checkout page.
In essence, teams can create pieces that other teams can use on their pages.
The micro frontends, however, can be deployed separately as different projects as opposed to the reusable components.
All of this sounds fantastic, but to create a unified interface, pages and fragments must somehow be combined.
This requires frontend integration, which can be accomplished via a variety of strategies, including routing, composition, and communication (see the graphic above).
When service from a page controlled by one team is required to access a page owned by another team, routing is useful for page-level integration.
Every micro frontend is handled as a single-page application. Simple HTML links can be used to provide routing.
A user can compel the browser to download the target markup from a server and replace the current page with the new one by clicking on hyperlinks.
No matter the library or framework that is being used, meta-frameworks enable the fusion of various pages into a single one.
Composition is the process of arranging the pieces to fit them into the appropriate spaces on a page. In most cases, the team that deploys the page doesn’t immediately fetch the content of the fragment.
Instead, it places a placeholder or marker where the fragment ought to be in the markup.
Using a different composing process, the final assembly is accomplished. The composition can be divided into two basic categories: client-side and server-side.
Client-side composition: The web browser is used to create and edit HTML markup. Each micro frontend has the ability to change and show its markup separately from the rest of the page.
Web Components, for instance, allow you to carry out this type of construction.
The plan is to turn each fragment into a web component that can be independently installed as an a.js file, after which the apps can load and render them in the spaces designated for them in the theme layout.
Web components are dependent on the HTML and DOM API, which other frontend frameworks can use, as well as a standard method of sending and receiving data via props and events.
Server-side composition: With this design, the UI pieces are combined on the server, which results in a completely formed page being sent to the client-side, speeding up loading.
The assembly is often carried out by a separate service that sits in between the web browser and the web servers. CDN is one instance of the service (content delivery network).
You could choose one or a combination of the two, depending on your needs.
Micro frontend communication patterns
The micro-frontend architecture works best when there is little to no interaction between the various components. Micro frontends occasionally need to talk to one another and share information. Here are a few potential patterns that might lead to that.
- Event emitter: In this case, many components communicate with one another by listening for and acting on any state changes in the components to which they are subscribed. Other micro frontends that have subscribed to that specific event respond when a micro frontend fires that event. An event emitter that has been introduced into each micro-frontend makes this feasible.
- Callbacks and props: In this section, you define a parent component and child components. The communication is organized into a tree-like structure. Parent components utilize props to convey the data as functions down the component tree to the child components. In turn, the kid can efficiently alert the parent when anything occurs in their state by responding to callbacks. React employs this mode.
Pros of Micro frontend
Development in Rapidly Autonomous Teams
An independent team can create each part of a web app or website when using a micro frontend method.
Each team is completely autonomous, which means it is in charge of the whole component development cycle, from conception to release and post-production.
Additionally, it implies that various teams can collaborate seamlessly while simultaneously working on the same project.
Therefore, release cycles are substantially quicker than they would be with front-end monoliths.
Smaller Codebases of Individual Micro Frontends Lead to Cleaner Code
Monolithic front ends have large, unwieldy codebases that become increasingly chaotic and challenging to manage over time.
Micro frontends address this problem. Each micro frontend’s source code is more manageable since it is smaller, simpler, and more compact.
The overall web solution benefits from cleaner code as a consequence.
Improved app stability Because of a Loose Coupling
A web solution can seldom ever be divided into completely independent pieces. Consequently, micro frontends do speak to one another.
However, each link between the components is significant despite the loose connectivity.
The failure of one component has little to no effect on the operation of all the other components, which provides the enhanced stability of a web solution.
Testing Individual Features is Made Simpler
This benefit results from the characteristics of micro frontends. Based on this architectural design, a web solution’s client side is modular and each module is autonomous.
As a result, evaluating a small portion of the user interface by itself is easier for a team to do than testing a massive monolith.
Reduced Bundle Size Leads to Quicker Page Load
A browser does not have to download unneeded code repeatedly since a web page is made up of several tiny bundles. As a result, page performance and load times are increased.
Multiple front-end frameworks can be used by developers to create a single online solution with a micro-frontend architecture.
Since each component is autonomous, it can be constructed using whichever technology suits the team’s tasks the best.
Naturally, programmers should use caution when selecting frameworks for the software project they are in charge of, and consultations with other teams are still strongly advised.
However, there is zero chance that you will be forced to use a legacy framework for the duration of the app’s lifespan.
Cons of Micro Frontend
Complex Web solution testing in its entirety
Testing a web solution’s various modules is easy when it uses a micro-frontend architecture. It differs from evaluating a web application as a whole, though.
Verify that all parts function as intended before continuing. This might be difficult since micro frontends operate independently and have separate delivery processes.
Expensive Initial Investments
Micro frontend developments typically demand substantial financial outlays. It is expensive to assemble and keep up many front-end teams.
Additionally, you’ll need management personnel to organize the job, make sure everything is coordinated, and guarantee excellent team communication.
The complexity of Development and Deployment
The development and deployment procedures can become more complicated as a result of a micro-frontend design.
A solution could be cluttered with too many components by independent development teams working on the same project, for instance, which could cause problems at the deployment stage.
The right assembly of all the modules and their smooth integration into the overall scheme is also not always simple; this work typically necessitates a thorough understanding of all the dependencies.
Problems Maintaining Coherence in the User Experience
Maintaining a consistent user interface is challenging when teams work separately on several parts of the software.
The web solution should be shared by all of the project’s developers. Otherwise, there can be a lot of contradictions along the road.
Micro frontends, a contemporary architectural design, can greatly enhance the performance of large-scale microservice-based web development projects.
It enables programmers to divide the complete solution into discrete parts that can be created by several autonomous teams. Numerous benefits follow from this, including quicker feature roll-out, easier testing of individual modules, and more seamless upgrades.
But there are some difficulties with micro frontends as well.
An application’s comprehensive testing, for instance, could be challenging.
Additionally, because a large team of engineers and administrators is needed, micro frontend projects are highly expensive.
Consequently, before coming to a decision, you must take into account all components of your business case.