Suggest an edit

Improve this article

Refine the answer for “What does the "Micro-frontend" approach do with React?”. Your changes go to moderation before they’re published.

Approval required

Content

What you’re changing

Title (EN)

Short answer (EN)

Shown above the full answer for quick recall.

Answer (EN)

## What Micro-frontend is

> **Micro-frontend** is an architectural approach in which a frontend application is split into **many small, autonomous parts** -
> each implementing its own feature, built and deployed **independently**,
> and in the browser these parts are "assembled" into a single whole.

Analogy:

> Backend world: **Microservices**
> Frontend world: **Micro-frontends**

---

## The main idea

An ordinary SPA becomes a "monolith" over time:

- complex, hard to update;
- multiple teams get in each other's way;
- one deploy breaks everything.

**Micro-frontend** solves this by:

- Each team owns *its own fragment of the interface (feature / domain)*;
- These fragments integrate into a *shared shell* (**Shell / Container App**);
- Each fragment can be deployed **independently**.

---

## Structure of a Micro-frontend system

```javascript
┌──────────────────────────┐
│       Shell / Host       │  ← the React container app
│ ┌──────────────────────┐ │
│ │  Micro-app #1       │ │  ← independent React (or Vue, Svelte)
│ ├──────────────────────┤ │
│ │  Micro-app #2       │ │
│ ├──────────────────────┤ │
│ │  Micro-app #3       │ │
│ └──────────────────────┘ │
└──────────────────────────┘
```

Each **Micro-app** can have:

- its own React and dependencies,
- a separate CI/CD pipeline,
- its own repository,
- an independent release cycle.

---

## How this works in React

### 1. **Host (the container app)**

The main React app, which:

- renders the "shell" (layout, navbar, router),
- dynamically loads micro-frontends,
- ties them together (navigation, shared context).

### 2. **Remote (micro-apps)**

Each micro-app exports its own components (for example, a page or a widget).

### 3. **Module Federation (Webpack 5)**

A technical mechanism that lets *one application load modules from another right at runtime*.

---

## Example: structure with Webpack Module Federation

```javascript
/shell-app
  webpack.config.js
  src/App.jsx

/profile-app
  webpack.config.js
  src/Profile.jsx

/dashboard-app
  webpack.config.js
  src/Dashboard.jsx
```

### Shell (host)

```javascript
// shell/webpack.config.js
new ModuleFederationPlugin({
  name: 'shell',
  remotes: {
    profile: 'profileApp@http://localhost:3001/remoteEntry.js',
    dashboard: 'dashboardApp@http://localhost:3002/remoteEntry.js',
  },
});
```

```javascript
// shell/src/App.jsx
import Profile from "profile/Profile";
import Dashboard from "dashboard/Dashboard";

export default function App() {
  return (
    <div>
      <h1>Main shell</h1>
      <Profile />
      <Dashboard />
    </div>
  );
}
```

> Now `Profile` and `Dashboard` are **separate React applications**,
> loaded by URL but running within one UI.

---

## Advantages of the micro-frontend architecture

| Advantage | Description |
|---|---|
| **Independent development** | Teams can work and ship autonomously |
| **Different technologies** | React, Vue, and Svelte can be used in different zones |
| **Independent deployment** | Updating one micro-frontend does not require releasing the whole system |
| **Faster CI/CD** | Small builds, separate pipelines |
| **Isolation** | A bug in one module does not break the whole UI |
| **Simplified scalability** | Teams can own their domains (auth, billing, dashboard, and so on) |

---

## Disadvantages and complexities

| Problem | What needs to be considered |
|---|---|
| **Integration** | Shared styles, design system, routing, event buses |
| **Shared state** | Sharing Redux/Zustand between micro-frontends is hard |
| **Bundle size** | Duplicated dependencies (React, libs) without optimization |
| **Deployment orchestration** | You need to manage module versions and compatibility |
| **Security and isolation** | Controlling access, sandboxing, CORS |
| **Performance** | Many separate loads mean more requests |

---

## Ways to integrate micro-frontends

| Approach | How it works | Example |
|---|---|---|
| **Module Federation (Webpack 5)** | Dynamic loading of JS modules on the client | `shell` + `remoteEntry.js` |
| **Single-SPA** | A meta-framework for registering sub-applications | `registerApplication()` |
| **iframe-based** | Each micro-frontend in an iframe (simple isolation, but weak integration) | `<iframe src="...">` |
| **Runtime Composition (Import Maps)** | Using native ES module imports | `importmap.json` |
| **Server-Side Composition** | The server "stitches together" HTML fragments | Edge-composition, Tailor.js |

---

## Examples in real projects

| Company | Where it is used | Features |
|---|---|---|
| **Netflix** | The home page, "Rows", and "Player" are separate micro-frontends | Fast independent releases |
| **Spotify** | The Library, Search, and Player sections | Different teams, a shared shell |
| **Amazon** | Product, Cart, Reviews | Separate JS bundles for each domain |
| **GitHub** | Pages and Settings are independent micro-frontends | Teams can transition without a monolith |

---

## Summary

| What | Description |
|---|---|
| Idea | Split the frontend into independent, autonomous modules |
| Structure | `Shell (Host)` + `Remotes (Micro-apps)` |
| Integration | Through Module Federation / Single-SPA / iframes |
| Goal | Scalability, independence, team flexibility |
| Pros | Isolation, fast releases, mixed technology |
| Cons | Shared state, routing, versions, integration |

---

> **Main idea:**
> Micro-frontend is a way to build a **React ecosystem as a set of independent microservices**,
> where each piece of UI is a separate application with its own life,
> but to the user it looks like **one whole**.

Markdown · drag & drop images · ⌘B / ⌘I shortcuts818 words

For the reviewer

Note to the moderator (optional)

Visible only to the moderator. Helps review go faster.