What are Micro Frontends?

Micro frontends are an architectural concept, based on the principle of breaking down your app into smaller apps with their own repositories that focus on one feature. This architecture can be used in many ways and allows for a great degree of flexibility.

For example each app can be implemented using different frameworks. Or, it could be used in a prescriptive manner by providing tools and thus enforce design decisions. Both of these approaches have their advantages and disadvantages, which will depend on the needs of your organization.

One important point to note about micro-frontends is that even though an app is split into multiple projects, the apps would still be integrated at the end into a single page App. A parent runtime would manage the app's lifecycle, giving it the feel of a single-page application.

When should this architecture be used?

Splitting an app into separate pieces and features can be useful in certain contexts, where there are a log of different features in a single app. Rather than building a monolithic app and integrate features tightly, you can build them separately. You experience this on your mobile phone. You have a phone app, a texting app, and a contacts app. They are working as stand alone apps, because they serve very different purposes, but they are sill integrated with each toher.

When you start building a Micro frontend architecture, there are four things that you must decide, early in the process: Definition, Composition, and Communication. Each of these coerstones plays an important role in the project's outcome.

1. Definition

First, identify the Micro frontend and the way it devides the app. Is it horizontal or vertical?

Horizontal splits allow different teams to work on different frontends but within the same view. For example, for a ecommerce page a team is responsible for the header, another team for the footer, a team for the content and a team for the shopping cart and so on.

A vertical split creates slices of the app - not unline slices of piza. In the above example, every team would work on the header, footer, content and shopping cart. But on separate pages. This reduces coordination among teams and is closer to the way a frontend developer works.

2. Composition

There are three choices when it comes to composing micro frontends: client-side or edge-side. Client-side refers to implementing a technique such as an application shell for loading single-page applications. Edge-side uses Edge Side Includes (ESI) or a similar technique at the edge. There are many frameworks for server-side, such as OpenComponents and Piral.

3. Communication

Different Micro frontends should be viewed as separate units when communicating with other Micro frontends. You can use custom events to notify other Micro frontends when an interaction occurs on a page that has multiple micro frontends. There are several options for exchanging data between Micro frontends that are distribued on several pages. You can use local storage to persist information that other Micro frontends need. Or, you can use the backend for the sharing of information.

Methods to Implement Micro Frontends

There are several methods to implement Micro frontends. Note that the actual implementation is completely up to you: there are no dedicated frameworks available.

1. Meta frameworks like single-page application (SPA) frameworks allow you to combine multiple JavaScript libraries/frameworks on runtime. These elements make up for the Micro frontends.
2. Multiple SPAs at different URLs. This is the easiest way to have multiple micro frontends. You can have different SPAs when you visit different URLs.
3. iFrames. Applications can use iFrames to encapsulate functionality. iFrames can use the Window.postMessage API for coordination between Micro frontends.
4. Web components. This approach uses a JavaScript wrapper that turns Angular/React and any other component into web components.

The Key Principles of Micro frontend Implementations

1. Be technology agnostic

Each team should have the ability to upgrade and choose their stack without needing to coordinate with others. The use of custom elements is a great way for implementation details to be hidden while still providing an interface to other teams.

2. Isolate

Even if you use the same framework, create independent apps that can be used independently. Do not rely on global variables or shared state.

3. Establish Team Prefixes

In cases where isolation is not possible, agree on naming conventions. Namespace CSS, Events and Local Storage, Cookies are all useful to avoid collisions and clarify ownership.

4. Favor Native Browser Features over Custom APIs

Instead of creating a global PubSub system, use Browser Events to communicate. Keep it simple if you have to create an API for cross-team communication.

5. Create a resilient site

Even if JavaScript fails or isn't yet executed, your feature must be usable. To improve perceived performance, you can use Universal Rendering or Progressive Enhancement.

Putting Micro Frontends into Perspective

It is helpful to look at the most common architectural patterns used today in order to give Micro frontends context and see where they fit.

• Monolith. Programmers of this type of architecture are usually full-stack programmers. They often work on both the front and back ends.
• Fontend/Backend. Here a separate group of programmers takes care of the front-end development, often known as front-end developers/engineers. The other group, who work on the back-end and on databases, are known as back-end developers/engineers.
• Microservices. This architectural styles allow applications to be broken down into loosely connected Microservices. There are specific teams that implement each service as independent unit.
• Micro frontends. As applications becomes more complex in the backend, so does the front-end. Breaking down the front-end to handle the complexity makes development more flexible.

Key Benefits of Micro Frontends

Independent teams. Each team can work independently from other teams since there is ideally no dependency between them. Each team is responsible for the complete life cycle of the feature.

Technology agnosticism. Every team can use its own technology stack, regardless of the technology used by other teams.

Simplified testing. Testing becomes simplier, when only smaller parts of the complete app need to be tested after changes have been implemented.

Better maintenance. Maintaing smaller parts of the whole app makes it easier easy to deploy updates and shortens build times.

Conclusion

Micro frontends shine of you’re building a large application or if you’re working with a large amount of people/teams. They are also a very good fit if you use microservices as your back-end architecture already.

Since there isn’t any standard for implementing micro frontends, you won't find actual frameworks. You have
freedom of choice when it comes implementing Micro frontends. We'd recommend you check the different patterns and solutions before you start implementing this approach. In comparison with a monolithic approach, you have definitely have a lot of advantages.

Sources:

1. Infoq
2. Increment
3. Medium
4. Toptal