“A rose by any other name…”

‘Micro frontends’ is the name given to frontends when they are implemented as a distributed codebase. The benefits and challenges of micro frontends are similar to those of microservices or any other distributed architecture.

As you’ll see in this article, many of these challenges result from distributed codebases maintained with tools and practices designed for centralized codebases.

We’ll see how Bit can help you solve these challenges and maintain a distributed codebase with the simplicity and ease of a centralized codebase but without its many drawbacks.

We’ll use the ‘Forever Mars’ demo project to demonstrate how Bit solves the different challenges presented to us.

The app is a booking website for one-way travel to Mars. It’s composed of two MFES, the homepage and the booking form.

1. Duplicated Code and Inconsistencies

Problem

Simple and small codebases are great; however, teams working on separate repositories can easily end up with duplicated code.

This can lead to inconsistencies in the UI/UX and to a lot of wasted time and effort.

Solution

Maintain your entire codebase as Bit components. This way, you can easily share and reuse components across different projects.

Bit components can be thought of as super-packages. They can be installed and used in any project but can also be updated and versioned independently of any specific repository or build setup.

Why is it important to develop and version components independently?

It allows you to maintain a single source of truth for components, which is not tied to any specific repository.

Instead, independently versioned components are hosted as isolated pieces of code in a remote scope, a remote component hosting.

This way, you get to reuse code across different projects and suggest changes straight from the consuming project — no context switching, no need to understand an entire codebase, and no need to wait for the component’s maintainers to approve your changes.

This significantly improves component collaboration and adoption across different teams.

2. Consistent Dev Standards and Tools

Problem

Different teams might have different standards and tools for development, testing, and deployment.

This can lead to inconsistencies and a lot of wasted time and effort.

Solution

Use Bit reusable development environments to maintain consistent development across different projects.

This way, you can define and share the tools, configurations, and dependencies required to build and test your components.

As mentioned, Bit components are not coupled to a specific git repository or build setup.

The tools and configurations required to build and test a component are configured directly on the component itself using Bit’s reusable development environments (which are also Bit components).

3. Dependency Management and Duplicated Libraries

Problem

Different teams might have different dependencies and versions, leading to bloated bundles and even runtime errors.

Solution

Use Bit’s reusable development environments to maintain consistent dependencies across different projects. In addition, use Bit’s dependency graph insight and tools to track and manage the dependencies of your components.

4. Routing, Global State, and Communication

Problem

Different teams might use different routing strategies, global state management solutions, and communication patterns.

Solution

Implementing your MFEs integration in build time (as opposed to in runtime) is the first major step to simplifying any sort of context sharing, whether it's routing, theming, authentication, or any other global state management.

As it has become obvious by now, Bit allows you to enjoy many of the benefits of runtime integration without many drawbacks.

Although Bit supports any sort of MFE implementation, it is highly recommended to use it to integrate your MFEs at build time and to share and reuse content providers. Bit also allows you to wrap your isolated component previews with these shared contexts.

To keep your project testable and maintainable, it is highly recommended to keep your global states as decoupled and agnostic to their consumers as possible.

Implement design patterns that improve composability and reusability, such as the pub-sub pattern, dependency injection, or any other sort of inversion of control.

5. Local Development and Testing

Problem

Teams working on different micro frontends don’t enjoy the same local development and testing experience working on a single monolithic codebase.

Solution

Maintain the shell application in the repositories that maintain the micro frontends. This way, you can develop and test the micro frontends in the context of the shell application and ensure that they work well together.

This solution has been made possible since Bit components are not coupled to any specific repository. That includes the “app component,” which is the shell application.

To try it out for yourself, clone the ‘booking’ repo and run the app locally (make sure to install Bit on your machine before running these steps):

git clone https://github.com/cosmos-cruises/booking.git
cd booking
bit install
bit run forever-mars