Micro Frontends can either make your applications flexible and robust or become an overhead and hinder the growth of your project.

And, there are many practices out there that might mislead any reader who is just entering into Micro Frontends.

In this article, I will go through some of these common mistakes so that you can avoid them whenever possible.

1. Splitting the Application Incorrectly

Many developers often misunderstand the idea ofMicro Frontends and get into trouble.

To employ this technique, we should break down our Monolithic Frontend (Opposite of Micro Frontend) into smaller, manageable pieces. But we should be cautious not to divide it too finely.

Some of the commonly faced problems that may occur due to bad division is as follows.

1. Increase of features/code that have to be “Shared” among Micro Frontend teams.
2. Difficult to keep track of the “shared” components.
3. Feature/Improvement dependencies across Micro Frontend teams that would adversely affect the development progress.
4. Harder to update, test, and deploy a component individually.

Ultimately, this would require joining all the components back together or increase the coordination between the teams, and we would be back to a Monolithic architecture in no time!

As a result, we miss out on all the advantages anticipated from the Micro Frontends and end up with many overheads in project progression.

What’s the solution?

There are two solutions to this problem.

Vertical manageable slices (Traditional)

One solution is to split the teams around vertical manageable slices of functionality rather than technical capabilities.

This will ensure autonomous teams with end-to-end ownership of their components, which will make the development process accelerated, scaled, and efficient as expected.

Independent Components (Modern)

Independent components are fairly a new concept in web development, and as such, they're often misunderstood.

The basic idea is this -

We are using technologies designed for monolithic projects to build apps and services that are structured with components.

Your versioning system couldn’t care less if it versions a component, a full project, or a recipe for noodle soup. Your dev tools and build workflows — all presume a full project (that is why, for example, Storybook is so widely used- we need a way to render and test components outside the context of a specific project).

Bit changes all that with components that can be developed and composed together in a single workspace, while still remain completely independent. They are developed independently and versioned independently (unlike your traditional VSC, Bit understands ‘components’).

Since Bit is all about independent components — it is an obvious choice for any sort of microarchitecture.

2. No Design System In Place

When we develop an application by integrating a collection of components, it’s essential to have a clearly defined, uniform design system implemented across all the components.

The lack of a design system leads to several inevitable issues.

1. Code duplication due to reduced discoverability:

Splitting the code into different teams will reduce the discoverability of the code. If a design system is not planned correctly beforehand, each team will end up duplicating the same functionalities in different components across the application.

Overheads occurring due to code duplication:

• Time would be wasted on reimplementing existing components.
• Increases the risk of missing an instance or misunderstanding the difference between two similar components.
• A change in the design of a specific component must be changed in more diverse places across multiple teams.
• Harder to track and fix bugs.

2. Inconsistency:

When the teams are not in agreement on the design of each component, the user will experience inconsistencies in different parts of the application.

An upgrade to a particular element has to be implemented in every different component it is utilized. As a result, there’s a high chance we might miss upgrading some parts, which again leads to inconsistencies in the UX.

3. Harder to keep track of the communications between the Micro Frontends:

In an application, Micro Frontends need to communicate with each other to change, refresh, or trigger an action in a part of the application.

Without the implementation of clear ground rules on the interfaces to communicate, these connections will be harder to track and maintain as the application grows.

Therefore, before starting implementing the Micro Frontends, it’s better to develop a proper design system that enables the autonomy of the codebases and teams so that the application won’t end up being messy.

3. Poor Code Sharing Methods

When several teams work on different frontend parts, some components are bound to appear across multiple Micro Frontends. The best way to implement these shared components is to reuse them by sharing the components across teams instead of duplicating code by reimplementing.

However, unless you are using a Monorepo, sharing these components as NPM packages can create a lot of problems.

1. It’s hard to test the compatibility of a shared component with the rest of the components in a specific Micro Frontend.
2. It’s hard to keep track of the versions of the shared components used across different Micro Frontends. Dealing with varying versions across the system could cause conflicts and errors in the application as a whole.
3. It’s hardto integrate a new version (update) of a shared component.
4. It’s hard to manage the CI/CD lifecycle for each component.

A Solution with Bit

Such hassles can be easily avoided by using non-other than Bit. Each independent component developed with Bit is also published as a standard Node package with auto-generated package.json .

With Bit, we don’t have to keep track of the dependencies of each component manually because it automatically creates a dependency graph for each component, including the version used, based on our source code.

Since all the versions of a component are available in the Bit platform, the teams can upgrade the shared component in their workspace to the new version at their own pace. Thus, each team can release changes and updates independently and continuously.

4. Incorrectly Identifying the Foundation and Integration Methods

Another common mistake when it comes to Micro Frontends is to think about the way you set up the foundation for the project.

Thoroughly think about the structure of your application and the capabilities of your teams when deciding on the way you split the application and the way you integrate it at the end.

Deciding on the Foundation

Sometimes, we end up having the wrong foundation or reducing the agility of the development.

1. Using an application shell for the foundation is one approach we commonly use with Micro Frontends. With the shell approach, there is an application shell, which composes the different Micro Frontends. If you follow this approach, you have to set proper ways of communication by identifying the right division, typically through URL parameters.
2. Splitting into Multiple Micro Applications is another approach to divide Micro Frontends. However, sharing code and optimizing the bundles could become a significant bottleneck unless appropriately managed.
3. Using Independent Components is another approach, which uniquely addresses the problem. It has a learning curve, understanding of the concept, and using platforms like Bit to manage the component sharing.

Deciding on the Integration Method

The Micro Frontends can be integrated either at build time or runtime. Typically we choose runtime integration over build-time due to the following reasons.

1. Build-time integration can cause syncing issues due to the versioning of components.
2. In build-time integration, you have to recompile and release the whole application to release a change in a single component.
3. The final bundle size might get larger if lazy loading isn’t properly configured.

So, you will have to think of these concerns and use platforms like Bit to manage them.

5. Trying to Mirror Microservices

It’s no longer a secret that Microservices influence Micro Frontends. However, there are significant differences among these two, which we need to be aware of.

1. Microservices are distributed and use different programming languages, tools, technologies &, etc., which is the best fit for establishing robustness. However, this isn’t entirely true with Micro Frontends, where we have to develop consistency that demands similar technologies, tools, and practices.
2. Microservices don’t encourage sharing but favor more autonomy. However, with Micro Frontends, reuse is essential for consistency and reduce bundle sizes that affect performance.
3. Microservices defines separate state management, storage for isolation. With Micro Frontends, though we can decide some level of autonomy, ultimately, these will end up as a single application to the end-users. Therefore, it’s not entirely possible to isolate since Micro Frontends have to depend on shared resources in the browser like Browser Storage, History APIs, URL Parameters &, etc.

Conclusion

If implemented correctly, Micro Frontend architecture is a great technique to establish clear boundaries across developing teams while ensuring the right level of coupling and cohesion.

Keep in mind to carefully understand your teams’ capabilities and scale and draw up a clear design plan before jumping into execution!

I hope that the information given in this article will save you from trouble and guide you through a mess-free, pleasant developing experience.