Micro Frontends: Concepts, Challenges, and Our Solution

If you are interested in the implementation details of part 2, this article will outline the concepts behind micro frontends.

What Is It and Why Do I Need It?

When a single‑page application (SPA) first launches, it is usually small and managed by a single front‑end team, which works well.

Over time the application grows, the team expands, and the large codebase brings many problems.

The term “micro‑frontend” has recently become popular; it brings a micro‑service‑like idea to the front end, allowing a single container app in the browser to load multiple independent micro‑apps, each with its own codebase and team, capable of independent testing and deployment.

(taken from https://micro-frontends.org/)

Although the concept sounds promising, practical implementations—especially ones that can be applied to existing large applications—are still lacking.

Choices

One possible solution is to use classic iframes, which provide strong encapsulation and independence but suffer from serious scaling issues.

Besides iframes, the term “Web Components” has also emerged.

Web Components let you create custom DOM elements that run independently and provide separation and CSS encapsulation; however, they are still far from a complete solution because key features like Shadow DOM lack full browser support.

Our Solution

At Outbrain we faced the typical problems of large SPAs: a massive front‑end codebase and a huge team making the app increasingly unwieldy. Seeing no satisfactory micro‑frontend solution in the wild, we set out to build our own that could be quickly realized on our existing ecosystem.

We defined several key principles that any solution must satisfy:

Independent Mode

Each micro‑app should be able to run completely independently, allowing its owning team to work without relying on other teams.

This means each app lives in its own repository and can run locally on a developer’s machine as well as in development and test environments.

Deployment

Each service can be deployed independently to any environment, including production, so that a bug fix can be released without involving other teams.

Testing

Tests run per micro‑app, making bugs easy to isolate. Some integration tests are still needed to verify interfaces between apps, and all teams should monitor them.

One‑to‑Many

Micro‑apps should be reusable in multiple places; they only need to know their inputs and outputs, not where they are used.

Runtime Isolation and Encapsulation

Each app must be sandboxed at runtime to prevent interference, covering CSS encapsulation, JS namespace isolation, and HTML separation.

Shared Resources

To avoid loading large modules (e.g., Angular, lodash) repeatedly, micro‑apps should be able to share common resources while allowing different versions when needed (e.g., one app using lodash 3 and another migrating to lodash 4).

Communication

A decoupled mechanism is required so apps can communicate via predefined interfaces and APIs without needing to know each other’s internals.

Backward Compatibility

Since we do not intend to rewrite the massive codebase, the solution must be insertable into the current system and allow gradual independence managed by other teams.

Web Components

Finally, any solution should align as closely as possible with the concept of web components, which, although still a concept, appears to be the future direction.

Part 2

In the next section I will detail how we implemented this solution and the steps we took.

The upcoming content covers Angular, Webpack, and some tasty loaders.

Original article: https://medium.com/outbrain-engineering/micro-front-ends-doing-it-angular-style-part-1-219c842fd02e

Local copy: http://pub.intelligentx.net/micro-front-ends-doing-it-angular-style-part-1

Discussion: join the Knowledge Planet or the Chief Architect Circle.