マイクロフロントエンド① 基礎学習

将来マイクロサービスの案件に携わってみたく、マイクロフロントエンドという言葉にも前々から興味があったので勉強してみることにしました。

#マイクロフロントエンドって何？
各マイクロサービスが提供する画面を結合することで単独のアプリケーションのようにふるまうものをマイクロフロントエンドといいます。各画面の開発はそれぞれ別のチームが行います。一方で、UIを単独のアプリケーションが担っている(１つのプロジェクトにすべてのコードが入っている)状態をモノリシックフロントエンドといいます。

eコマースを例にすると、商品リストとショッピングカートの画面を各チームが別々に開発するような状態がマイクロフロントエンドにあたります。
![スクリーンショット 2021-03-13 14.13.50.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/569054/78da54c0-2370-a27e-d06e-4496bc24be9e.png)

画面間のデータのやりとりは直接ではなくAPI経由で行います。このように各画面は完全に分離されているので、チームごとに使用するフレームワーク(React, Vueなど)が異なっていても問題ありません。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/569054/1f02391b-90b2-d83c-c368-c0247ba835cf.png" width="700">

#メリットは何？
- 複数の開発チームが独立して画面を作成できる(異なるフレームワークやライブラリが使える)
- 機能ごとにアプリケーションを分割するので保守性が高い(理解、修正のコストが低い)

#プロジェクト作成
商品リストとショッピングカートの表示を各々のプロジェクトにわけて、簡単なマイクロフロントエンドを実装してみました。

##構成
商品リスト(ProductsList)とショッピングカート(Cart)の他に、それらの表示を司るコンテナ(Container)というプロジェクトも作成します。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/569054/3aa16684-03be-2561-4a89-29abbf5a43e8.png" width="500">

##プロジェクトの統合
コンテナが各プロジェクトを統合する方法にはいくつかあります。それぞれに長短があるので、それらを理解した上で選択する必要があります。

- Build-Time Integration(Compile-Time Integration): コンテナがブラウザでロードされる前に各プロジェクトのソースコードを取得する。
- Run-Time Integration(Client-Side Integration): コンテナがブラウザでロードされた後に各プロジェクトのソースコードを取得する。
- Server Integration: コンテナのコードをサーバでロードしている間にサーバが各プロジェクトのソースコードを取得するか決める。

###Build-time integration
各プロジェクト(ProductLists, Cart)をデプロイしてnpmのパッケージとして公開し、それらのdependencyをContainerプロジェクト上でインストールするような流れになります。実装の流れはわかりやすいのですが、プロジェクトとContainerとの結合度が高いことや、コードを更新するごとにContainerも再度デプロイしなければいけないという問題があります。

###Run-time integration
まず、各プロジェクト(ProductLists, Cart)が`https://my-app.com/productslist.js`などにデプロイされます。ユーザがmy-app.comにアクセスしたときにコンテナがロードされ、`productslist.js`を取得します。この方法だとセットアップが少し複雑になりますが、いつでもプロジェクトをデプロイすることができ、いろんなバージョンのプロジェクトをデプロイした場合にも、コンテナ側で取得するコードを選択することができます。

##セットアップ
`ecomm`フォルダに`products` `cart`のプロジェクトと`container`を作成します。

###パッケージ導入
次にプロジェクトに必要なパッケージを導入して、`webpack.config.js`ファイルを作成します。

products, cart

```
npm init -y
npm install webpack@5.4.0 webpack-cli@4.5.0 webpack-dev-server@3.11.0 faker@5.1.0 html-webpack-plugin@5.1.0
```
container

```
npm init -y
npm install  nodemon webpack@5.3.2 webpack-cli@4.5.0 webpack-dev-server@3.11.0 html-webpack-plugin@5.1.0
```

フォルダ構成は以下のようになります。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/569054/b7e85c60-1649-8a05-11e3-9d519061c87e.png" width="300">

###プロジェクト連携
containerとproducts, cartを連携するために、Webpackの`ModuleFederationPlugin`を使用します。
このプラグインでは、プロジェクトにホストかリモートの役割をつけ、リモートのプロジェクトではファイルを外部に公開する設定を行い、ホストのプロジェクトでは指定したリモートのファイルをインポートするように設定することができます。今回はcontainerをホスト、productsとcartをリモートとします。

リモートの`index.js`ファイルは`ModuleFederationPlugin`によって3つのファイルに出力されます。

- `remoteEntry.js`: プロジェクトで利用可能なファイルのリスト+ファイルのロード方法に関する内容を含むファイル
- `src_index.js`: ブラウザでロードされる`src/index.js`を変換したファイル
- `faker.js`:  ブラウザでロードされるfaker(モックデータ生成用のnpmパッケージ)を変換したファイル

ホストのプロジェクトでは、`bootstrap.js`でproductsとcartのファイルをインポートし、`index.js`で`bootstrap.js`をインポートするような構成にします。

```bootstrap.js
import 'products/ProductsIndex';
import 'cart/CartShow';
```

```index.js
import('.bootstrap');
```
すると、`index.js`ファイルはWebpackによって2つのファイルに出力されます。

- `main.js`: `index.js`を変換したファイル
- `bootstrap.js`: `bootstrap.js`を変換したファイル

ファイル(products, cart)を取得する処理を`bootstrap.js`に分けたのは、**必要なファイルを取得した後に、`bootstrap.js`を実行するような順序にするためです。**

この流れをまとめると以下のようになります。
![スクリーンショット 2021-03-13 20.05.28.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/569054/cca4a2ad-38c2-4740-36e3-717ae3a37312.png)

また、ModuleFederationPluginの設定は`webpack.config.js`で行います。

ホスト(container)

```webpack.config.js
new ModuleFederationPlugin({
  name: 'container', //プロジェクト(PJ)名(任意)
  remotes: { //取得したいリモートのPJのリスト
    products: 'products@http://localhost:8081/remoteEntry.js', //[インポートするときの名前]: [(リモート側で設定したPJ名)@(remoteEntry.jsのURL)]
    cart: 'cart@http://localhost:8082/remoteEntry.js',
  },
}),
```

リモート(products)

```webpack.config.js
new ModuleFederationPlugin({
  name: 'products',
  filename: 'remoteEntry.js',
  exposes: {
    './ProductsIndex': './src/index', //ファイルのエイリアス(名前置き換え)
  },
}),
```

リモートのファイルをホスト側でインポートする際はimport 'products/ProductsIndex'と記述します。`node_modules`内に該当する名前のdependenciesがないため、productsのProductIndex(src/index)をインポートすることができています。

container, products, cartで`webpack serve`を実行するとlocalhostの各ポート(8080, 8081, 8082)でWebpack DevServerが立ち上がります。`localhost:8080`にアクセスすると商品リスト(products)とカート(cart)が表示されています。
![スクリーンショット 2021-03-13 20.52.29.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/569054/5dc8ecec-efe1-7126-94b0-2f7d2fb4ec83.png)

＊productsとcartのプロジェクトにある`index.html`は各チームで開発する際の表示確認用にしか使われず、本番では使われません。

##ファイルの共有
dev-toolのNetworkタブをみてみると、productsとcartで同じパッケージを使っている都合でfakerが2つロードされています。同じファイルがロードされるとその分重くなるので、ファイルの共有でこの問題を解消します。
![スクリーンショット 2021-03-13 9.37.31.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/569054/89f97972-2374-0609-485b-aff9952a162d.png)

`shared: ['faker']`をproductsとcartの`webpack.config.js`に追記するとfakerが1つしかロードされなくなりました。簡単ですね。

```webpack.config.js
new ModuleFederationPlugin({
  name: 'products',
  filename: 'remoteEntry.js',
  exposes: {
    './ProductsIndex': './src/index',
  },
  shared: ['faker'],
}),
```
![スクリーンショット 2021-03-13 9.46.29.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/569054/9d68febb-956d-b5bf-89c3-b81e485cd1f2.png)

しかし、cartの`localhost:8082`にアクセスしようとすると、開けなくなっていました。どうやら、fakerをインポートする前にindex.jsを実行してしまうみたいです。
![スクリーンショット 2021-03-13 9.48.51.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/569054/2d07d740-afb7-df67-e8eb-a453f94bf7b5.png)

containerと同様に、`index.js`の中で`bootstrap.js`を読み込むような構成(非同期処理)にしてみたらちゃんと開けるようになりました。

また、productsとcartsで違うバージョンのfakerを用いたときは、ファイル共有を行っても2つのファイルがロードされるようです。どうしても共有したい場合には、singletonを使えば大丈夫なのですが、この場合、バージョンに関するwarningがでます。

```js
shared: {
  faker: {
    singleton: true,
  },
},
```

#おわりに
将来役立つ日がくると信じて、次はReactとVueでマイクロフロントエンドを実装してみます。

#参考資料
https://www.udemy.com/share/103KXSCEEZd11VRno=/

https://micro-frontends-japanese.org/