Micro Frontend: A Complete Guide

“If you're already a front-end developer, well, pretend you're also wearing a pirate hat.”   ― Ethan Marcotte

What one sees at the front end of a website is far off from the technical reality beneath it. Developers experience a unique virtual reality that is full of modular structures. The frustration of these developers, while collaborating on large complex apps, is what drove the motivation behind micro frontends.  

The trend of micro frontends began 5 to 6 years ago when web applications started becoming complex. The need to slice up this complexity into smaller patterns became clear. These semi-independent patterns that can be developed by separate teams are what we call Frontend Monoliths.

So What Exactly are Micro Frontends?

‍

Micro Frontends are designed to break down the frontend monolith into smaller, more manageable chunks. Each team can own its features from start to finish, develop in its codebase, release versions independently, offer minor incremental upgrades regularly, and interface with other teams to compose and manage pages and applications together.    

We can look at Micro Frontend as an extension of Micro Services. Martin Fowler, Chief Scientist at ThoughtWorks defines Micro Frontend as “an architectural style where independently deliverable frontend applications are composed into a greater whole.”  

‍

Three Ways to Spilt the Application

‍

1. By page – In frontend applications, having multiple pages open in the browser at the same time can cause a crash on devices, therefore splitting by page is the safest option. You may run distinct, specialised micro-apps for each page if you have appropriate routing, which is also good for your devs because they will always work on the one page given to them.  

2. By functionality – If you have a single page with many features doing distinct actions, you may break those large features down into smaller apps and make each one a standalone application.  

‍

3. By section - You can also divide your apps into sections, with several apps sharing the same section or component.  

‍‍

Top Benefits of Micro Frontend

‍

Every time one needs to deploy an application, (at least those who work on it will know) it takes around 10 to 15 notes to build and deploy an application. That's a huge amount of time for a one-time production patch.  

‍

1) Increases autonomy of independent teams

‍

Micro-frontends are great tools for helping teams work autonomously by dividing teams first and code second. Each team has complete control over a vertical slice of the programme and can specialise in their field. They won't have to worry as much about unintentional interference from other teams, and they won't have to coordinate as much.  

‍

2) Eases organisation of code and artefacts  

‍

Micro-frontends, in principle, can help you enhance the structure of your codebase by containing a smaller, concentrated section of the application in each micro-frontend. It's a common misconception that monolithic apps can't be adequately structured; in fact, a few minor tweaks can provide one with just as many benefits as totally dividing your application.  

‍

3) Eases the deployment process  

‍

One has the opportunity to distribute pieces of your frontend independently with micro-frontends. You can merely deploy what has changed rather than redeploying everything. You can also give teams the freedom to release whenever they choose, without having to coordinate with other teams or adhere to a company-wide release cycle. You can undo a faulty release without harming other teams' work.  

‍

4) Multiple technical choices  

‍

The last widely stated advantage of micro-frontends is that it allows everyone to use a variety of front-end development frameworks and technologies. While a small team is unlikely to wish to learn and use numerous frontends at the same time, it does provide an upgrade route when it comes to future tools and frameworks.  

Instead of needing all teams to coordinate updates, micro-frontends allow each team to upgrade their technology stack separately. Supporting several tech stacks also makes it easy to include off-the-shelf solutions, independent of the framework.  

‍

‍Most-used Frameworks for Micro Frontend Architecture

‍

Micro frontends can take a variety of forms, ranging from smart component integrations at build-time to run-time integrations using bespoke routers. Any team may take a modular approach to design web apps and reap these benefits with the correct component model and technologies.  

A compiled a list of the most widely used tools for creating micro frontends:  

‍

1) BIT

‍

BIT is a standard component infrastructure that aids in the composition of programmes using components. It enables teams to design and deliver products quickly and autonomously while ensuring that everything and everyone in the company is always integrated. It also allows for cloud collaboration and reuse of all components, allowing for rapid development scaling.  

‍

2) Single SPA  

‍

Single SPA is a “framework for bringing together multiple JavaScript micro frontends in a frontend application.” In a nutshell, it gives every application a lifecycle. Each app must know how to bootstrap, mount, and unmount itself from the DOM and respond to URL routing events.  

Note: The key distinction between a standard SPA and a single-span application is that the latter must be able to live with other apps and does not have its HTML page.  

‍

3) Webpack 5 & Module Federation  

‍

Module Federation allows JavaScript applications to dynamically import code from another application at run-time. It mainly tackles the problem of code dependency and increased bundle size by enabling dependency sharing.  

Module Federation is a more efficient approach to sharing code and exposing any code from any application. The same code can be used in different environments, such as web, Node.js, and so on.  

Also read: Technology and culture: Two sides of the same coin

‍

Common issues of Micro Frontend: A short peek into Repos

‍

A repo is short for a repository that stores all of a project's changes and files, allowing developers to "version control" the project's assets as it progresses through development. Splitting the application into separate repos inflames most of the major difficulties with micro frontends.  

The multi-repo strategy employs numerous repositories to house the services of a company's project. It will contain every minimum set of reusable code or standalone functionality (such as a microservice) under its repository at its most extreme.  

‍

1) Sharing a common function

‍

The multi-repo strategy employs numerous repositories to house the services of a company's project. It’s tough to share libraries across multiple repos.  

It involves uploading artefacts to a package registry, where repos define a version range as a dependency. Worse, shared code usually has its repository, which necessitates creating build tools, unit testing, and continuous integration. Inheriting changes to shared code necessitates changing the package's dependence, which is a headache in itself.  

‍

Resolving the issue with Mono Repo 1.0:

‍

Creating a shared library in a mono repo is as simple as making a new file and importing it into other projects. Moreover, these imports can be analysed statically, and dependencies may be inferred from the source code. Because IDEs can identify the real source code rather than a compiled build output of a dependency, tracing code through imports is significantly easier.  

Not only does having code in the same repository reduce the likelihood of inconsistencies in general, but consistency may also be ensured by automation. Making micro frontends more consistent with one another allows developers to move between projects more easily and deliver value where it is needed most.  

‍

2) Managing application-wide changes

‍

Making a change across numerous micro frontends necessitates altering multiple repositories when micro frontends are split up into distinct repositories. This means that a commit must land in each repository, and different teams' releases may need to be synchronised. Even if the change's code is housed within a common package, each repository must still update the dependency's version.  

‍

Resolving the issue with Mono Repo 2.0:  

‍

In a mono repo, all of the changes can be made in a single atomic commit. This can be accomplished by a single team specialising in application-wide improvements or by combining numerous teams' commits into a single commit.  

‍

Proof of concept with peopleHum

‍

‍