Theory of Micro Frontends

Share your Code. Sharing is Caring :)

Contents:

1. Microfrontends Definition
2. Why Microfrontends
3. Micro Frontend Reality
4. Pros and Cons
5. Summary & References

What are Microfrontends?

Microfrontends is the idea of extending the Microservices feature to Frontend Development. It is a new pattern where web applications are composed of semi-independent fragments that can be built by different teams using different technologies.

More Documentation: https://micro-frontends.org/

Architecture:

Web Apps have taken a greater character arc over the years of development.

Monolith Architecture

• Having all at one place with No Idea of sharing code/efforts.
• One big Repo - One Big Team

Micro Services Architecture

• Isolating your APIs to do their work. Frontend still stays together
• Different APIs - Different Teams - One Frontend

Micro Frontends

• Ever had Pizza??? ????
• Hell Yeah!!! That’s the base of Micro Frontends

Divide it into pieces and let others consume your Pizza. Don’t just keep it to yourself, share it. Sharing is Caring ??

Combine different modules combine to form a Micro Frontend. As simple as that.

Why Microfrontends?

• Over the past few years, IT companies have begun to break large software into smaller, easier-to-manage chunks and called them micro-services.

• The idea behind this approach is to have services modularized to the use case they operate on. Modularizing and decoupling the services based on their implementations would be helpful in making the features developed, tested, and deployed independently.
• This is what the microservice architecture is with regard to backend development. The same approach can be applied to front-end development as well. This would lead to building up End-to-End Teams responsible for a single feature. One Team - One Goal
• In this approach, different teams work independently to develop different components of an application front-end, and the resulting design is a lot more versatile.

What Made Micro Frontend A Reality?

Web components are the new normal of the app-building process. These reusable, modular pieces are inching toward claiming their true potential as the building blocks of web applications. Combining all of them into one single Monolithic-Structure will reduce the capability of these components can be delivered.

A shared infrastructure that is designed to support a component-driven modular design has a key role in the adoption of the Micro Frontend development approach at the organizational as well as architectural level.

There are multiple existing ways to share and import codes from other applications/websites. The following are some:

Iframes

• The <iframe> is an HTML element representing a nested browsing context, embedding another HTML page into the current one.
• iFrames effectively create “browser windows” within the existing page, a potential User Experience nightmare resulting in unintended nested and vertical scrollbars if not carefully configured.
• The isolated browsing context of an iFrame means that any link within an iFrame will redirect the iFrame’s location to that link while remaining on the original host URL inside the web browser.

Web Components

• Web components are a set of web platform APIs that allow you to create new custom, reusable, encapsulated HTML tags to use in web pages and web apps
• It doesn’t have the end-to-end isolation capability, Operates only as a wrapper and requires additional code for the component to work as expected.
• Framework Specific. Isn’t compatible with other frameworks.

Component Library

• A library/plugin published with a set of static components available to use as a part of the web app. Ex: Material Library
• Only operates on static components. It cannot be configured with apis.
• Framework Specific. Isn’t compatible with other frameworks.

Below is a detailed comparison of the primary expectations when sharing of web components is considered.

Micro frontends are capable of consuming a shared remote component, upgrading it to the next version, and sharing the upgraded version as a remote component again.

Build it your way, Share it, mold and use it the way you want.

Pros and Cons of Microfrontends

Pros:

Customised Elements scaling up to multiple teams

• When using customized APIs over native browser features, it is imperative to keep things as simple as possible. This helps streamline the operationality when building a cross-team API.

Adopting different tech stacks while Reusing the Shared Components

• The build time integration could be done using web components or any component-driven frameworks. So one of the approaches is to publish it as a package and then use a container application to indulge them as the library dependencies. So this integrates the components at the build time and helps keep a fully decoupled build pipeline for each of the frontends. This helps in achieving effective collaboration and code reuse.

Development and deployment become faster

• Faster and isolated development and deployment: The development process also highly improves by adopting its architecture. As with this architecture, we can have smaller independent teams that work on different features, and the development and deployment process becomes faster.

Isolating Team Codes

• The key to building independent apps is to ensure that they are self-contained. For this, you must isolate team code by not sharing runtime, even if all your teams are using the same framework for development.

Tech Agnostic Approach

• MFE provides the true freedom of independent development process. Every team working on different components of an application frontend should have the liberty to choose and upgrade their stack without consulting or coordinating with others. Using custom elements is an efficient way of making this happen, as they allow your teams to hide details of implementation when sharing a neutral interface with each other.

Cons:

Lack of Control Over Interfaces Between Modules

• If you need to work with another team's micro frontend for yours to function correctly, you may find that they don't always directly follow best practices or conventions set by your organization.
• As each application is self-contained and isolated from one another, this could lead to trouble down the line when trying to integrate them.

Risk of Lack of Communication

• Cross-functional teams are a common way to manage projects, but it can lead to wasted time and inefficiency.
• The problem arises when different groups work on the various codebases without sharing their workloads with other departments.
• This can lead to duplication of specific implementation methods and can hurt 'Frugality'

Increased Payloads

• Since the remote entries are downloaded before hand or lazy loaded along with the modules, the payload time should also be considered as a part of performance
• The more technology stacks and applications included, the slower it may be on a user's browser.

More Complex Development Process

• Code needs documentation and unit tests to be efficient and correct and easy enough for others to read through when they are trying to come up with new ideas or implementing updates from your product management team.
• If micro frontends were implemented without care, there could quickly become too much complexity within each separate module that makes it too complex for developers later down the line.

Cohesive UX

• For the user experience to remain cohesive and consistent, there must be a common understanding across teams.
• When different groups use multiple technologies within an organization, inconsistency in one area could lead others down similar tangents, making for an unpleasant overall user experience.

Summary

Micro frontends allow more flexible and scalable code development across your application and will enable each team to work independently.

• The remotely exposed components act as services independent of the consuming app's architecture.
• Any props, input attributes which are to be passed into the component can also be done as per the component's definition.
• Lazy loading of components and dependencies is also supported.
• Multiple Micro Frontends can be consumed as remotes into one single host application. Configuring the app URLs to the remotes will give the option to consume.
• Each Micro Frontend screen is independent of the other and wouldn’t effect the other components in the app if the original app is failing or updated.

Resources

Finally, I’d like to share some resources with you to explore further if you’re interested. I’ve listed them all here.

• https://micro-frontends.org/
• https://www.thoughtworks.com/radar/techniques/micro-frontends
• https://martinfowler.com/articles/micro-frontends.html
• https://aws.amazon.com/blogs/compute/server-side-rendering-micro-frontends-the-architecture/
• https://blog.bitsrc.io/revolutionizing-micro-frontends-with-webpack-5-module-federation-and-bit-99ff81ceb0
• "Decision Strategies for a Micro Frontends Architecture"

Implementation of Micro Frontends

Follow the above article for the upcoming next part, containing Steps of Implementation, Code, and Best Practices of MFE.