Complete Guide About Micro Frontend will be discussed in this article. “Pretend you’re also wearing a pirate hat if you’re already a front-end developer,” was the advice. I am Ethan Marcotte.
The technical reality hidden beneath a website’s front end is very different from what one sees there. The virtual world that developers encounter is distinct and full of modular elements. Micro frontends were developed as a result of the dissatisfaction these developers had while working together on huge, sophisticated programs.
Complete Guide About Micro Frontend In 2023
When web applications started getting more complex five to six years ago, the micro frontend trend started. It became obvious that this intricacy needed to be divided up into smaller patterns. We refer to these semi-independent structures as frontend monoliths because they can be created by different teams.
So What Exactly are Micro Frontends?
The goal of micro frontends is to divide the frontend monolith into more manageable pieces. Each team can take full ownership of its features, develop in its own codebase, independently release versions, provide minor incremental upgrades on a regular basis, and connect with other teams to jointly compose and manage pages and applications.
Micro Frontend can be seen as an expansion of Micro Services. Micro Frontend is described by Martin Fowler, Chief Scientist of ThoughtWorks, as “an architectural style where independently deliverable frontend applications are composed into a greater whole.”
Three Ways to Spilt the Application
- By page – In frontend applications, dividing by page is the safest approach because having numerous pages open in the browser at once can cause a device to crash. If you have the right routing, you may run different, specialized micro-apps for each page, which is advantageous for your developers since they will only ever work on the one page that has been assigned to them.
- By functionality – If a single page contains numerous features that perform various tasks, you can divide those huge features into smaller apps and create separate applications for each of them.
- By section – You may also categorize your apps into groups, with one group of apps sharing a portion or component with another group of apps.
Top Benefits of Micro Frontend
It takes roughly 10 to 15 notes to develop and deploy an application every time (at least people who work on it will know this). For a single production patch, that is a significant amount of time.
1) Increases autonomy of independent teams
By splitting teams first and coding second, micro-frontends are excellent tools for assisting teams in working independently. Each team can specialize on their area of expertise and has total authority over a vertical slice of the software. They won’t need to coordinate as much, and they won’t have to worry as much about other teams inadvertently interfering.
2) Eases organization of code and artefacts
In theory, micro-frontends can improve the structure of your codebase by encapsulating a more condensed, smaller portion of the application in each micro-frontend. Contrary to popular belief, monolithic applications can really be effectively structured with a few modest adjustments, which can have just as many advantages as completely separating your application.
3) Eases the deployment process
With micro-frontends, it is possible to distribute different parts of your frontend separately. Instead of redeploying everything, you can just deploy the changes. Teams can be allowed to release whenever they want, without being required to coordinate with other teams or follow a company-wide release calendar. A flawed release can be corrected without affecting the work of other teams.
4) Multiple technical choices
The ability to leverage a range of front-end development frameworks and technologies is the final benefit of micro-frontends that is frequently mentioned. A small team may not want to learn and utilize many frontends at once, but it does offer an upgrade path for potential future tools and frameworks.
Micro-frontends enable each team to update its technology stack independently rather than requiring all teams to coordinate updates. It is also simple to incorporate pre-made solutions with the support for many tech stacks, independent of the framework.
Most-used Frameworks for Micro Frontend Architecture
Micro frontends can take many different shapes, from run-time integrations utilizing custom routers to smart component integrations at construction time. With the right component model and technologies, any team may use a modular approach to develop web applications and enjoy these advantages.
The following is a index of the most popular tools for building micro frontends:
1) BIT
BIT is a common component architecture that facilitates the use of components in the creation of programs. It makes it possible for teams to build and deliver products fast and independently while guaranteeing that the entire business is always integrated. It also enables cloud collaboration and component reuse, enabling quick development scalability.
2) Single SPA
A “framework for combining multiple JavaScript micro frontends in a frontend application” is known as Single SPA. In a word, it provides a lifetime for every program. Each app needs to understand how to bootstrap, mount, and unmount itself from the DOM as well as how to react to URL routing events.
The main difference between a single-span application and a conventional SPA is that the latter must coexist with other apps and lacks an HTML page.
3) Webpack 5 & Module Federation
JavaScript apps can dynamically import code from other applications during runtime thanks to module federation. By enabling dependency sharing, it primarily addresses the issue of code dependencies and increasing bundle size.
A more effective method for exchanging code and making any code from any application visible is module federation. The same code can be used in a variety of settings, including web, Node.js, and others.
Additional reading: Technology and culture: The two halves of the same coin
Common issues of Micro Frontend: A short peek into Repos
A repository, often known as a “repo,” is where all of a project’s modifications and files are kept. This allows developers to “version control” the project’s assets as it advances through the development process. Most of the significant issues with micro frontends are exacerbated by splitting the application into distinct repositories.
The multi-repo technique makes use of several repositories to host a company’s project’s services. At its most extreme, it will have every minimal collection of reusable code or isolated piece of functionality (like a microservice) under its repository.
1) Sharing a common function
The multi-repo technique makes use of several repositories to host a company’s project’s services. Sharing libraries across several repositories is challenging.
In a package registry, where repos define a version range as a dependency, it entails uploading artifacts. Even worse, since shared code frequently has its own repository, building tools, unit testing, and continuous integration are required. It is a hassle in and of itself to alter the package’s reliance when inheriting changes to shared code.
Resolving the issue with Mono Repo 1.0:
Making a new file and importing it into other projects is all it takes to create a shared library in a mono repository. Furthermore, dependencies may be deduced from the source code and these imports may be statically analyzed. Tracing code using imports is much simpler because IDEs can locate the actual source code rather than a compiled build output of a dependency.
Automation can help to maintain consistency in addition to reducing the likelihood of inconsistencies in general by having all of the code in one repository. Developers may switch between projects more easily and provide value where it is most needed by improving the consistency of micro frontends.
2) Managing application-wide change
When micro frontends are divided up into different repositories, changing one micro frontend requires changing several repositories. As a result, a commit must be made to each repository, and it might be necessary to synchronize the releases of various teams. Each repository must update the dependency’s version even if the change’s code is contained within a single package.
Resolving the issue with Mono Repo 2.0:
A single atomic commit can be used to make all of the changes in a mono repository. This can be done by a single team that focuses on application-wide upgrades or by integrating the commits from several teams into a single commit.
Add Comment