Chapter 13無料公開

Build Time Composition

Build Time Compositionでは、ClientでもServerでもなく、Build TimeでFragmentsを結合します。

社内ライブラリ

npmなどで社内ライブラリ化する方法です。このケースでは、各々のMicro Frontendsでライブラリを読み込み使用します。例えば、社内で使われるUIコンポーネントをコンポーネントライブラリとして提供する、などがわかりやすいでしょう。

技術的には、重複コードのバンドリングや、スタイルのスコープ化などが考慮点となります。アプリケーションごとの整合性を保つため、インターフェイスの設計も慎重に行う必要があるでしょう。

また、どのチームが開発を担当するかは導入前に議論しておく必要があります。例えば、全員がコントリビューターになる分散開発的なパターン、「プラットフォームチーム」を設けてメインのメンテナ兼レビュワーをつけるOSS的なパターン、全ての開発を一つのチームが担当するパターンなどがあります。

単なるUIの「共通化」だとかえってコストが増えてしまうこともあるので、意味のあるライブラリにするよう注意する必要があるでしょう。

SSG

JAMstackのチャプターで説明したSSGの技術を使う方法です。例えば、以下のようなフローが考えられるでしょう。

この場合は、API化したFragmentsをBuild Timeで静的なコンテンツに変換します。

Bitの場合

Bitはコンポーネントドリブンで開発するためのツールで、ビルド、バージョニング、デプロイなどをCLIから簡単に行えるようにすることができます。Bitの特徴で面白いなと思ったのは、dependency graphという機能です。

例えば、下記のavatarコンポーネントやnav-itemコンポーネントがどのコンポーネントで使用されているかが把握でき、適切なバージョニングを行うことができます。

dependency graphをはじめとして、Build Time Compositionを行う際の開発フローに関して一種のフレームワークを提供しているのがBitを使用するメリットといえるでしょう。

メリット・デメリット

メリット

Build Time Compositionのメリットは、サーバーのリソースを考慮せずにSEOやパフォーマンスに関して有利になる点です。ランタイムの様々な考慮を減らしながらServer Side Compositionのメリットを享受できるのはBuild Time Compositionならではです。

デメリット

Build Time Compositionでは、デプロイを疎結合にすることができません。例えば、Build Time Compositionを想定したライブラリでは、その利用者側のアプリケーションでもう一度デプロイを行う必要があります。Micro Frontendsという観点ではここは大きなデメリットといえます。

また、アプリケーションによっては、Framework依存をしないようなインターフェイス設計が必要となります。

まとめ

Build Time Compositionでは、SSGの手法や、ライブラリ化のユースケースなどによるMicro Frontendsをみました。このあたりも使い所によっては選択肢の一つとして検討したいところです。