Module federation is a webpack 5 features. It allows independent deployments for you different applications. Same as [HTML import map](https://www.buzzchart.info/post/html-import-map)? Yes but it allows more flexible configuration and reuse not only JavaScript files.

## **What Module federation can do?**

- Can share individual JS modules together with it's dependencies. You can share a react component together with styles and static data.

- Can share any module, that webpack supports.

- Can share the whole application as a micro-front-end

- Must share a common libraries like react, react-dom and/or components library

## **Use cases**

- Independent applications deployment

- Independent pages deployment (aka mfe)

- Independent components deployment. To share components library for other "containers" to use.

Webpack Module Federation

How to load JS in the runtime, from a separate server? Browsers provide a native feature called [HTML importmap](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script/type/importmap). It is supported and works across all latest devices and browser versions.

**`importmap`** HTML feature is useful because:



- it allows to load modules by our specified rules and create a declarative configuration in the HTML.

- This configuration cannot be overriden and serves as a source of truth to our modules resolution configuration defined in on place.

- allows different modules to be loaded from the different sources. It enables independent deployment. Because we can specify different modules to be loaded from the different urls.

- when all JavaScript modules are loaded to the same main thread, conflicts can appear. this means, that for some imports we need to have one library resolved, for example **`react`** and **`react-dom`**.

- when we are referencing the same libraries from different modules, we may want to specify different urls to resolve these libraries. For example billing is using **`lodash@13`** and customer is using **`lodash@14`**. These versions are not compatible. To load each version for each module we can use **`scopes`** feature in the **`importmap`**.

## **What is an "importmap"?**

Importmap is a JSON declaration of imports and actual paths to be replaced in the JavaScript. We can declare an importmap as follows:

```html
<script type=importmap>
    {
      "imports": {
        "circle": "https://example.com/modules/circle.js",
      }
    }
</script>
```

With this declaration we can use **`import`** expression in our javascript just referencing **`circle`** as:

```javascript
import circle from 'circle'
```

## **What are the rules using importmap?**

- **`<script type='importmap'>`** must be defined before other scripts. This is the quote from a [HTML spec](https://html.spec.whatwg.org/multipage/webappapis.html#import-map)

> Import maps are currently disallowed once any module loading has started, or once a single import map is loaded. These restrictions might be lifted in future specification revisions.

- no other properties cannot be specified in this script tag. **`src`** property cannot be specified also.

- importmap impact only **`import`** and **`import()`** expressions in the JavaScript

- import map cannot be dinamically modified. Once it is loaded to the browser, it cannot be reloaded in the runtime.

## **Scopes**

Scopes feature allows to resolve different modules depending on the current module, from which the import is resolved. The scoping is achieved by specifying the "scopes" object in the import map, where each key is a scope URL, and its value is an object of import mappings that apply to that scope.

Consider this configuration of imports and scopes:

```json
{
  "imports": {
    "a": "/a-1.mjs",
    "b": "/b-1.mjs",
    "c": "/c-1.mjs"
  },
  "scopes": {
    "/scope2/": {
      "a": "/a-2.mjs"
    },
    "/scope2/scope3/": {
      "b": "/b-3.mjs"
    }
  }
}
```

results in the resolutions of modules:

```bash
"a"         "b"         "c"
/scope1/r.mjs           /a-1.mjs	/b-1.mjs	/c-1.mjs
/scope2/r.mjs	        /a-2.mjs	/b-1.mjs	/c-1.mjs
/scope2/scope3/r.mjs	/a-2.mjs	/b-3.mjs	/c-1.mjs
```

HTML Import Map

- Page based decomposition - each microservice has ts own dedicated page. This pattern enables vertical slice of an application. ✔️ You can deploy your UI and backend for a vertical slice of an application independently from other microservices. ❌ Has limited capabilities creating complex UI.

- Widget based decomposition - each widget can communicate only with it's own microservice. ✔️ You can deploy your UI and backend for a vertical slice of an application independently from other microservices. ❌ Adds complexity in managing communication between widgets.

- Central Aggregating gateway - gateway (with transformation, filtering, aggregation) as a single entrypoint to the microservices. Good fit when you have a separate UI teams and microservices teams. Creates horizontal layers of an application (n-tier architecture). ✔️ Simplifies UI development. ❌ Creates coupling on the gateway side.

- Backend For Frontend (aka BFF) - same as CAG per client type. This pattern fits, when you have multiple client types (web, ios, android, 3rd party API). ✔️ It solves the general purpose API problem and enables teams to develop independently. ❌ It creates coupling on the gateway layer, and introduces code duplication.

_patterns by Sam Newman from the book Microservices 2nd edition_