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 though this distributed manner of constructing the server-side of web apps is more or less reliable in terms of research and execution.
Due to their close dependency, the client-side monolith typically makes it difficult to integrate new features, adopt new technologies, and scale individual components.
Frontend developers have begun to consider microservices as a solution to these and other problems. As a result, a brand-new architectural strategy called micro frontend was developed for creating the front-end layer of websites and web-based applications. Since it was first used in 2016, the phrase has drawn a lot of attention—and for good reason.
This article will provide a high-level overview of micro frontends, including what they are, the issues they address, and how to use them. We’ll concentrate on this approach’s possible applications as well.
What are micro frontends?
The front-end of the program is divided into separate, loosely coupled “micro apps” that can be developed, tested, and deployed individually. This is known as a “micro frontend” architectural and organizational style (NOT a specific technology!!!). similar to how the backend is divided into several services in the world of microservices.
To put it simply, each micro frontend is just a piece of code for a distinct feature of the web page. These features are owned by separate teams, each of which specializes in a particular industry or objective.
For a better understanding, let’s have a look at the Instagram website as an example. We’ll use Patron, a stunning and courageous Ukrainian Jack Russell Terrier, as our case study for this. In any case, why not? 😇
So where might you implement micro frontends in this context? The navigation bar is first. In general, header and footer elements are typical targets for micro frontends. The block of saved stories comes next. The block with posts that can be turned into a separate service comes last.
Despite being very young, the micro frontend framework is already very well-liked by businesses looking to advance their online development. A notable early adopter of the micro frontend architecture is the enormous audio streaming corporation Spotify. It structures its development into independent, all-encompassing teams known as Squads.
After dealing with whats, it’s time to discuss hows. We’ll contrast the micro frontend with other methods for creating applications so you can better grasp how it functions.
Monolithic architecture vs microservices and micro frontends
Think of moving. 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 different web app architectures, monoliths and microservices (also known as micro frontends).
Monolithic architecture
You might be able to recall the “good old days” when a complete application was created as a single, cohesive unit. Such a method is called a monolith, which is an ancient 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 will break. Even though it is outdated, it occasionally still exists. Yes, we are aware of your current expression.
The conceptual division of the codebase into two distinct components — frontend (client-side) and backend (server-side) — became inevitable as new technologies developed and software products became 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 requires 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 difference 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
- Easy and fast development for small applications — the design is pretty straightforward with a single source codebase;
- Relatively simple testing and debugging — since all code is located in one place, a team can easily follow the flow of a request and find a bug; and
- Lower costs in the early stages of an application — there is no overhead either in infrastructure cost or development cost unless you start implementing new features.
The downsides of this approach reflect in
- Limited deployment flexibility — you need new deployment every time you make an update to code with teams having to wait if there are a few of them on the project;
- Difficulty in introducing new technologies — trying a new technology results in the need to rewrite a large part of — if not the whole — project;
- A single large codebase — a system of code is tightly coupled, complex, and hard to manage and understand when the number of developers grows;
- Scalability issues — since components of the project are interdependent, scaling them individually is challenging, causing substantial downtime and increased costs;
- Organizational problems — if many teams are working on the monolithic project, each team member must use the same version of libraries and notify of any changes; and
- The high entry barrier for new developers — new team members may find it hard to grasp the logic of the entire project especially if the developers who initially worked on it are not around.
Microservices and their siblings — micro frontends — were created to solve the main issues of monolithic architectures.
Microservices architecture
The architectural strategy of using many, loosely linked, and independently deployable smaller components or services to create an application backend is known as microservices. Each service has its own codebase, CI/CD pipelines, and DevOps procedures, and each service executes its own processes.
The monolith backend team is divided into separate teams, as can be seen in the image above. Each works separately on a certain aspect of the application (such as the product service, search service, and payment service).
Through established protocols known as APIs, such as the lightweight REST API protocol that uses synchronous request-reply patterns, communication between the services occurs. Another option is to choose asynchronous communication using software like Kafka, which offers publish/subscribe communication structures and events.
Microservices integrate with the frontend using 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 offer a single point of access for a collection of microservices.
But even with independent backend components and all the advantages they bring, the frontend is still a monolith.
So, here’s when micro frontends come into play.
Micro frontend architecture
The micro frontend architecture applies the concept to the browser and is similar to microservices, where loosely linked components are managed by several teams. These web application user interfaces follow this paradigm and are made up of partially independent pieces. Additionally, teams are established around a client requirement or use case rather than a talent or technology.
In an eCommerce site, for instance, two independent teams will be in charge of end-to-end development, code quality, user experience, and deployment for features like payment and search. Each squad has a specific, well-defined goal. Let’s use the following example: “Help the consumer locate the product they are looking for” can be the mission statement of the team developing the search functionality.
So, in projects based on microservices and micro frontends, teams are
- Vertically sliced — they develop their features end-to-end from the user interface to databases as there are not only frontend developers but also data specialists, backend engineers, QA engineers, etc., all working on one mission; and
- Cross-functional — each member shares their knowledge with the rest of the team.
Teams can also select the tech stack that best suits their particular line of business. One team can use React to program its fragment. A 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.
Better flexibility. Each micro frontend is self-contained, meaning it can be built, tested, deployed, and updated independently. So, if one team is working on a feature and has pushed a bug fix and another team needs to add its own feature, they don’t have to wait for the first team to finish their work.
Technology freedom. Frontend developers working on different fragments of UI can choose different runtime environments, JavaScript frameworks, and overall technology stacks based on business requirements. A new framework can be used on top of the old architecture.
Multiple, smaller codebases. Micro frontends will have their own codebases, each of which will be smaller in size and more manageable. There will be fewer developers working on a particular part of UI, leading to simpler code reviews and better organization of all things.
Easy app scaling. Another advantage of micro frontends is that each feature can be scaled independently. This makes the entire process more cost- and time-effective than with monoliths when the whole application has to be scaled every time a new feature is added.
Autonomous teams and systems. Each product team and therefore feature can operate with minimal dependency on others, which means it can function even when the neighboring components are down.
The lower entry barrier for new developers. Micro frontends are easier to understand and manage than UI that isn’t split up into smaller and simpler components. So, new players won’t have to spend ages learning the whole code before they start bringing value to the project.
How micro frontend works: Core ideas and integration patterns
As we’ve previously stated, teams are vertically organized within the micro frontend architecture, which means they are separated by domain knowledge or mission and are responsible from beginning to end for a specific product. It may include one or two backend microservices as well as a small frontend. Let’s examine this visual element’s characteristics, interactions with other UI components, and incorporation into the homepage in more detail.
A micro frontend can be
- A complete page (e.g., a product detail page) or
- Individual fragments of the page (e.g., headers, footers, search bars, etc.) that other teams may use.
You can divide up a big website into different page kinds and give each type to a specific staff to work on. However, there are several components that frequently occur on numerous pages, such as headers, footers, recommendation blocks, etc. A recommendation block, for instance, might be included on a homepage, a product detail page, or even the checkout page. In essence, teams can create fragments that other teams can incorporate into their pages. The micro frontends, however, can be deployed independently as different projects as opposed to the reusable components.
All of this sounds fantastic, but in order to create a single interface, both pages and fragments must be put together in some way. You need frontend integration for this, which uses many methods like routing, composition, and communication (see the viz above).
Routing
When you require a service from a page controlled by one team to get to a page owned by another team, routing can be used for page-level integration. Every single micro frontend is handled as a standalone program. It is possible to approach routing by utilizing only HTML links. When a user clicks a link, the browser is forced to retrieve the desired markup from a server and update the existing page with the new one.
For cases when a page must be rendered without reloads, you can opt for a shared application shell or a meta-framework like single-spa.
The barebones HTML, CSS, and JavaScript that powers a UI are known as the app shell. Even though the content data requested from the server is still pending, a user immediately receives a static displayed page. The single-page applications created by the various teams serve as children of the primary app shell.
Regardless of the library or framework being used, meta-frameworks allow the combining of various pages into a single unit. For instance, the single-spa architecture offers a number of options, including
- A module loader to load individual pages asynchronously;
- Separate wrappers for different UI components to connect them into a whole; and
- APIs for communication between individual applications, subscription to events, etc.
Composition
It takes composition to arrange the pieces so they fit properly on a page. Usually, the team that ships the page doesn’t immediately fetch the fragment’s content. Instead, it adds a placeholder or marker to the markup where the fragment ought to be.
A different composing process is used to create the final assembly. Client-side and server-side composition are the two main types.
Client-side composition. Direct HTML markup creation and modification take place in the web browser. Each micro frontend can independently update and display its markup on the page. This type of combination is possible, for instance, using Web Components.
Each fragment will be developed as a web component that can be independently deployed as a.js file, after which the applications will load and render them in the corresponding placeholders designated for them in the theme layout. The HTML and DOM API, which other frontend frameworks can use, as well as a standard method of sending and receiving data using props and events, are the foundations of web components.
Server-side composition. The client-side really receives a fully finished page using this approach because the UI components are combined on the server, which speeds up loading. Typically, a separate service situated in-between the web browser and web servers handles the assembly. CDN is an illustration of the service (content delivery network).
Depending on your requirements, you might pick one or a combination of both.
Сommunication patterns between micro frontends
Web workers. A web worker allows online content to run JavaScript in the background without interfering with other scripts or slowing down the performance of the page. A unique worker API will be provided for each micro app. The benefit of this is that time-consuming work can be done in a different thread, allowing the UI thread to proceed without being slowed down or halted.
Props and callbacks. A parent component and child component are defined here. The form of the message is that of a tree. The information is passed as functions from the parent components to the child components via props. By responding to callbacks, the child can efficiently alert the parent when something occurs in their state. React makes use of this mode.
Event emitter. Various components in this scenario communicate with one another by listening for and reacting to any changes in the states of 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 possible.
When you need and don’t need micro-frontends
Despite all of this, you might still believe that the micro-frontend design is a panacea. It’s obviously not, though. The micro frontend won’t magically alleviate all of your pain spots, as with any methods. To determine if this approach is appropriate in your particular situation, it’s crucial to balance the advantages and cons.
When micro frontend is a good idea
Medium to large projects. The method of creating micro frontends is excellent for scaling development and, as a result, works well for bigger projects with numerous teams. Micro frontends are advantageous if you are working on a sizable eCommerce site like Zalando, for example.
In 2015, Zalando – one of the biggest retail players – decided to move away from a monolithic shop system and opt for the microservices for the frontend. They called it Project Mosaic. The approach allowed the company to distribute the work on the main website between a large number of teams which resulted in faster delivery of features and better scalability.
Web projects. Although the idea of micro frontends is platform-agnostic, the web is where it shines the brightest. The design of native apps for iOS and Android is monolithic. On-the-fly composition and replacement functionality won’t be possible.
Productivity-focused projects. Teams that are vertically divided increase productivity overall. However, there are additional expenses and maintenance difficulties. Micro frontends can be thought about if productivity is your top priority and you’re prepared for overhead.
When micro frontend isn’t a good idea
Projects with unclear vertical cuts. You must be knowledgeable about the industry you work in. If it’s unclear which team will be most suited to deliver a specific feature, you risk having a messed-up work structure, added complexity, and fewer gains.
Small projects. What can be accomplished fast and efficiently utilizing a common monolithic method doesn’t need to be overly complicated. With tiny and straightforward websites, this is the case. You don’t have to employ the new style everywhere just because it’s popular.
Therefore, before implementing the micro frontend framework, be aware of your motivations and keep in mind that this design approach may not be suitable for all users. Yes, this is a tendency that is currently the subject of lively discussion in the neighborhood. Yes, this architecture will be used by a lot of large companies. But in the case of a bulk application, all of this matters. The purpose of micro frontend is lost if a website has many pages. Already, it is overhead.
In addition, the design faces a few other difficulties, such as the need to write more redundant front-end code. Not to mention that micro frontends are intricate designs that are challenging to use and keep up.
Reference: Micro Frontends, Explained | AltexSoft
