Blessing Krofegha
27 Jul 2021
•
7 min read
Large applications have profited in several ways as a result of microservices improvements. It aids with the development, deployment, and scaling of separate components of the application backend. Nonetheless, many people noticed that the front end faces comparable issues. That's where we start breaking down the frontend monolith into micro frontends.
Modern online applications are more complicated, with multiple teams managing them at times. You may have features in your application that were created by separate teams, and you wish to deploy only a few of them into production before releasing the full application. If you just have one repository, how do you manage many teams and release schedules?
The majority of these complicated programs are client-side, making them more difficult to maintain. This monolithic large application has a few other flaws as well.
In this article, I'll go over the benefits, drawbacks, implementation, of typical micro-frontend architecture.
Micro-frontend codebases can be smaller, more manageable.
By definition, micro-frontends should have smaller codebases than monolithic frontends. This detached code is easier to browse, and developers are less likely to make mistakes as a result of the complexity. Developers are typically able to go through code more quickly and with less effort, in addition to having higher correctness. This is especially true when developing process-driven apps that may already involve the development of complex processes.
Micro-frontends promote reusability across process and case management
Micro-frontends are very useful for businesses that develop a number of different apps with similar workflow requirements. Enterprises may use this design to extract common parts from case management functions, saving time and effort when building new processes. For example, if a company has many sites that require a workflow for payment processing and the other automated business processes it triggers, they may reuse the same functionality across all of their apps rather than having to develop it from the ground up each time. By using the ability to design and create a frontend component once and reuse it in a number of scenarios, this reusability may help businesses save a significant amount of time and money over time.
Micro-frontends allow you to democratize user experience User experience may be the misery of many modern development teams. In a world where software is constantly being created and deployed, a centrally controlled UX may quickly become a bottleneck. Microservices democratized backend development, but micro-frontends extend the service-oriented mindset to every stage of the development lifecycle. Enterprises may more completely adopt a robust microservice-like mindset by breaking apart a frontend monolith. This method enables cross-functional teams to produce both frontend and backend functionality independently. Instead of focusing on offering a specialized skill set, these teams are vertical, focusing on delivering a specific use case or product from start to finish. This reduces bottlenecks by breaking down departmental walls and promoting greater collaboration between backend and frontend engineers.
Build-time integration
This type of approach publishes each micro-frontend as a package and then lets the application container build them as library dependencies.
The following is an example of a package.json
that is based on Cam Jackon’s micro-frontend demo:
{
"name": "@feed-me/container",
"version": "1.0.0",
"description": "A food delivery web app",
"dependencies": {
"@feed-me/browse-restaurants": "^1.2.3",
"@feed-me/order-food": "^4.5.6",
"@feed-me/user-profile": "^7.8.9"
}
}
Run-time integration via Web Components
Web Components are a collection of technologies that enable you to design reusable custom elements. Custom elements, shadow DOM, and HTML templates are the three primary technologies. It's a sort of "Runtime integration via JavaScript" that's unique. The only distinction is that you choose to work with Web Components. Cam Jackson gives an example of a micro-frontend built with Web Components:
<html>
<head>
<title>Feed me!</title>
</head>
<body>
<h1>Welcome to Feed me!</h1>
<!-- These scripts don't render anything immediately -->
<!-- Instead they each define a custom element type -->
<script src="https://browse.example.com/bundle.js"></script>
<script src="https://order.example.com/bundle.js"></script>
<script src="https://profile.example.com/bundle.js"></script>
<div id="micro-frontend-root"></div>
<script type="text/javascript">
// These element types are defined by the above scripts
const webComponentsByRoute = {
'/': 'micro-frontend-browse-restaurants',
'/order-food': 'micro-frontend-order-food',
'/user-profile': 'micro-frontend-user-profile',
};
const webComponentType = webComponentsByRoute[window.location.pathname];
// Having determined the right web component custom element type,
// we now create an instance of it and attach it to the document
const root = document.getElementById('micro-frontend-root');
const webComponent = document.createElement(webComponentType);
root.appendChild(webComponent);
</script>
</body>
</html>
From these choices, which type of micro-frontend approach will you choose?
For good reason, the notion of Micro Frontend is all the rage in the development industry right now. It's a fantastic answer to a variety of front-end development issues. It's only logical that you'd want to include it in your development procedures. However, if not done correctly, it can be time-consuming, resulting in more hurdles than answers. So, before you begin shortlisting frameworks for your Micro Frontends, consider the following five factors:
You may decide to use Cam Jackson's micro-frontend technique. You may either come up with your own indigenous solution or borrow ideas from others. The frameworks specified in the Awesome Micro Frontends project are as follows:
There is no dominant micro-frontend approach yet. You can always pick up an existing solution to start with.
Micro-frontends add a new level of complexity to frontend development. We've seen the use case of breaking down an application into two parts: old code and newly developed code, on one end of the spectrum. On the other hand, we've seen the strategy of creating a slew of little micro-frontends, such as global types, time services, and i18n services. There are no hard and fast rules for determining which path is proper. It is entirely dependent on your use case and team chemistry. When developing micro-frontends, keep the following facts in mind:
These considerations will influence how you design micro-frontends and how you select a micro-frontend framework. If you create modules properly, the more micro-frontends you have, the less coupling you'll have.
By separating code and encouraging independent development, Micro Frontends provide a reliable method for dividing the burden among multiple teams. These current solutions and frameworks are widely utilized because they serve as the backbone of this revolutionary approach to front-end development. If you're just getting started, it's a good idea to look at their use cases before deciding on the best frameworks for a large-scale project.
Blessing Krofegha
Blessing Krofegha is a Software Engineer Based in Lagos Nigeria, with a burning desire to contribute to making the web awesome for all, by writing and building solutions.
See other articles by Blessing
Ground Floor, Verse Building, 18 Brunswick Place, London, N1 6DZ
108 E 16th Street, New York, NY 10003
Join over 111,000 others and get access to exclusive content, job opportunities and more!