MadVue

In this presentation I'll talk about MFEs, what they are and their usefulness. I'll talk about their different kinds, structure-wise and architecture-wise.

MFEs, what are they?

The approach where a large (monolithic) web application is broken down into smaller, (semi-)independent "micro apps".

This breaking down could happen for each domain with BFFs or Databases. Or for different routes. You could also think of different reusable components like a newsletter subscription box.

Micro Frontend architecture can be structured in a variety of ways, but over all, let's break them down into the two main structures: monorepos and multi-repos. Inside each structure, you could explore different architectural. For example if you want each app to represent a route and then bundle all the apps at build time. Or you could think of something like Web Components if you want component-level integration.

Monorepos are great for tightly integrated and smaller teams. - code sharing is easy and frequent - and there is centralized control.

Codebase is a single repo with separate folders. You usually have a main app, and any other apps you want for example for different UIs.

Multi-repos are better for organizations with larger teams that are independent and need more isolation and control.

In a real world situation, you may want a hybrid structure. You may want a central monorepo for the core of your platform, with reusable layers, shared components like your ui-library, internal toolings, ... And some independent repos (or let's say external MFEs). Where each micro frontend lives in its own repo but pulls from core platform, that centralized monorepo. This pulling could be via npm package (usually a private registry) (published from monorepo), Git submodule, or other tools This way, Shared code evolves rapidly in monorepo while MFEs stay independent and teams own their pipelines and their domain.

Duplication reduces, and you can adopt incrementally (meaning you can build or migrate one MFE at a time.)