Micro frontends is one of several architectural approaches that help developers to break down large web applications into smaller, independent parts.

Each micro frontend application represents a self-contained feature or module that can be developed, tested, and deployed separately from the other micro frontend applications.

This article provides a practical guide for organizations wishing to adopt micro frontends. For further reading on micro frontends, read our previous post “Microfrontends: Microservices for the Frontend”.

Slicing the Monolithic ApplicationThe main challenge with adopting the micro frontends architecture isn’t technical. Instead, the discussion often involves the product team and relates to your vision of the application.

Luca Mezzalira defines two ways of slicing monolithic applications:

1. Vertical slices: slices are defined by URLs, and each page is sliced into its own micro frontend application.
2. Horizontal Slices: pages are split into multiple micro frontend applications. For example, teams often own a group of applications that cover specific flows.

To demonstrate the complexity behind this decision, let’s envision a simple e-commerce site that we split into two domains:

1. storefront
2. admin panel

Splitting the site vertically makes perfect sense here, as the two domains are relatively self-contained.

Let’s imagine that after a few years the CEO wants to expand the company by allowing other sellers to offer their products through the site. This can be easily achieved by creating a new vertical slice for a partner’s portal domain.

A more complex change would be adding a new line of products to the store, which would require some changes from the current lineup. For this we can split the storefront into two new slices, i.e. books and perishable goods sections.

We can duplicate some code to ensure that the domains remain isolated but, as they grow, the cost of maintaining duplicate code can quickly outgrow its benefits.

To handle this, we can adopt horizontal slicing by defining domains based on user flows, i.e. the discovery process and purchase.

Each domain will include components that can exist on one or more pages and allow the related teams to own those user journeys.

In summary, vertical slices offer:

1. Simpler technical implementation
2. Pages are more cohesive, as the same team and product managers own them.
3. Payload size per page tends to be smaller, especially when multiple frameworks are used.

On the other hand, horizontal slices offer:

1. More freedom when slicing applications.
2. Flows rather than pages tend to be more cohesive.
3. Expanding the application is easier.

While there are strong technical benefits from using vertical slices, the decision needs to consider product needs and future growth.

Implementing vertical slices without clear independent domains becomes very hard to maintain, while the cost of horizontal slicing can easily exceed its short to medium value. This means that you have to choose which you want to implement carefully.

Incremental Upgrades?One of the main selling points for micro services and micro frontends architecture is the easier upgrade path you gain by managing multiple small applications that can be changed independently.

While this is a significant benefit, there are two additional considerations to discuss for micro frontends:

1. Bundle size: grows exponentially for every new library we add. This affects load times which have a direct effect on the user journey.
2. Shared components: it’s not trivial to share components between libraries, and while there are solutions, they impose limitations on your choices of libraries and development flows.

As a result, some companies chose to implement micro frontends using a single library such as React. While this might sound counterintuitive, it simplifies the adoption process, reduces bundle sizes, and can remain relevant for many years.

Micro Frontends ImplementationsiframesIframes are by far the simplest implementation for micro frontends, which ticks all the required boxes:

1. Technology agnostic: allowing each application to use its own set of libraries.
2. Self-contained: each application runs within its context, and each application can be built, tested, and deployed individually.
3. Easy to implement: rolling out a bespoke solution is easy, and since each application provides its HTML file, the build process does not change radically.

Developers who wish to use an existing solution should take advantage of Luigi, an open-source library created by SAP, as it handles some of the more complex use cases such as cross iframe communication, 3rd party cookies, etc.

It’s worth noting that iframes work best for vertical slicing and that, despite the benefits, it has not gained wide traction in the community. As such, this option should be considered for smaller projects that need to get running quickly.

Module FederationModule federation is a relatively new feature in bundles, such as Webpack, that allows separate JavaScript applications to share and consume code at runtime.

It offers two exciting possibilities for developers:

1. It can reduce bundle sizes by sharing common libraries, such as lodash, across multiple micro frontend applications. This is especially useful for the previous iframes implementation example.
2. Companies that choose to forgo incremental upgrades and use a single library like React can use module federation to manage the loading of the different micro frontend applications.

A great Github resource demonstrates how to use Webpack module federation with different setups that provide a good starting point.

Module federation works best with single library projects that rely on vertical slicing. Horizontal slicing is possible but requires a more complex setup.

Single SPASingle spa is a popular library for managing more complex micro frontend applications.

It supports a sophisticated router called the Layout Engine that allows developers to easily combine multiple micro frontend applications that use different libraries within the same layout. This provides much better flexibility than standard vertical slices while avoiding much of the complexity of horizontal slicing. At the same time, it supports true stand-alone components called Parcels but advises limiting their use as they are rather complicated to manage. Single spa is a great solution for most complex applications that do not rely heavily on horizontal slicing.

Bit.devBit.dev is a tool for composing component-driven applications where a single component can be as small as a button or as big as an entire page. Bit.dev aims to fulfill the promise made by Web Components by allowing developers to freely combine components from different libraries into a single application while avoiding many of the hurdles that exist with Web Components. Unlike previous solutions, Bit requires a dedicated server where components are managed, organized into scopes, and shared across projects. It’s an exciting solution that is gaining popularity in companies like Tesla and Ebay but may not be ready for large enterprise-grade projects.

ConclusionMicro frontends can provide a valuable tool for organizations looking to scale their frontend applications. Adopting the right tool for the job, as with anything else, will have a lasting effect. Organizations should allocate time for technical investigation and align the technical domains with the product vision. Following the KISS design process is recommended when investigating technical solutions. Avoid selecting more complex solutions such as single spa and bit.dev that require deeper integration with the development process unless it’s clear that your organization will use its unique capabilities.

The post Starting With Microfrontends appeared first on Semaphore.