トップ > MicroFrontends > Micro Frontends を調べたすべて

Micro Frontends を調べたすべて

MicroFrontends

Photo by Dil on Unsplash

Micro Frontendsに関わる記事を100件以上読みました(参考記事に記載しています)。そこから得たMicro Frontendsについてこの投稿に記録します。 また、調査メモについて、次のリポジトリに残しています。 github.com

発端

www.thoughtworks.com

実績企業

Pros/Cons

Pros

観点 内容
独立性 ・任意のテクノロジーと任意のチームで開発可能
展開 ・特定の機能をエンドツーエンド(バック、フロント、デプロイ）で確実に実行可能
俊敏性 ・特定のドメインについて最高の知識を持つチーム間で作業を分散すると、リリースプロセスが確実にスピードアップして簡素化される。
・フロントエンドとリリースが小さいということは、リグレッションテストの表面がはるかに小さいことを意味する。リリースごとの変更は少なく、理論的にはテストに費やす時間を短縮できる。
・フロントエンドのアップグレード/変更にはコストが小さくなる

Cons

観点 内容
独立性 ・独立できず、相互接続しているチームが存在しがち
・多くの機能で複数のマイクロフロントエンドにまたがる変更が必要になり、独立性や自律性が低下
・ライブラリを共有すること自体は問題ないが、不適切な分割によって作成された任意の境界を回避するための包括的な場所として使用すると、問題が発生する。
・コンポーネント間の通信の構築は、実装と維持が困難であるだけでなく、コンポーネントの独立性が取り除かれる
・横断的関心事への変更ですべてのマイクロフロントエンドを変更することは、独立性が低下する
展開 ・より大きな機能の部分的な実装が含まれているため、個別にリリースできない
・サイト全体の CI / CD プロセス
俊敏性 ・重複作業が発生する
・検出可能性が低下した結果、一部の標準コンポーネントを共有できず、個別のフロントエンド間で実装が重複してしまう。
・共有キャッシュがないと、各コンポーネントは独自のデータセットをプルダウンする必要があり、大量の重複呼び出しが発生する。
パフォーマンス ・マイクロフロントエンドの実装が不適切な場合、パフォーマンスが低下する可能性がある。

統合パターン

bluesoft.com

統合 選択基準 技術
サーバーサイド統合 良好な読み込みパフォーマンスと検索エンジンのランキングがプロジェクトの優先事項であること ・Podium
・Ara-Framework
・Tailor
・Micromono
・PuzzleJS
・namecheap/ilc
エッジサイド統合 サーバーサイド統合と同じ ・Varnish EDI
・Edge Worker

CDN
・ Akamai
・ Cloudfront
・ Fastly
・CloudFlare
・ Fly.io
クライアント統合 さまざまなチームのユーザーインターフェイスを 1 つの画面に統合する必要があるインタラクティブなアプリケーションを構築すること ・Ajax
・Iframe
・Web Components
・Luigi
・Single-Spa
・FrintJS
・Hinclude
・Mashroom
ビルド時統合 他の統合が非常に複雑に思われる場合に、
小さなプロジェクト（3 チーム以下）にのみ使用すること		 ・ Bit.dev
・ Open Components
・ Piral

機能

コミュニケーション

developer.mozilla.org github.com

データ共有

  • ストレージ
    • URL
    • Cookie
    • Local Storage/Session Storage

モジュール共有

  • webpack

webpack.js.org webpack.js.org webpack.js.org

ルーティング

Vaddin router vaadin.com

キャッシュ

developer.mozilla.org developer.mozilla.org

認証

  • JWT

jwt.io

計測

Real User Monitoring

  • SpeedCurve
  • Catchpoint
  • New Relic
  • Boomerang.js
  • Parfume.js
  • sitespeed.io

Synthetics Monitoring

  • Lighthouse
  • WebpageTest

Proxy

コンポジションプロキシ。テンプレートを組み合わせる。 github.com

アクセス履歴

developer.mozilla.org

分割ポリシー

フロントエンドを分割する方針について

  • 水平分割
    • 画面内にある要素で分割
    • ビジネス上の機能
  • 垂直分割
    • 画面毎に分割

Webサイト⇔Webアプリ

document-application

※ Microfrontends: An approach to building Scalable Web Apps

マイクロフロントエンドは、かなりのオーバーラップがあるバンドの中央部分の大部分に最も適しています。バンドの両極端に該当するプロジェクトにマイクロフロントエンドアーキテクチャを実装しようとすると、生産性に反するそうです。

リポジトリ

パターン Pros Cons 技術
モノリポ コードベース全体に簡単にアクセスできる。
(検出可能性が高い)		 モノリポジトリは、特に大規模なチームで作業しているときに、
動作が遅くなる傾向があり、バージョン管理下のコミットとファイルの数が増加する。		 ・nx.dev
・lerna
マルチリポ ・マルチリポジトリは、非常に大規模なプロジェクトと
それに取り組む非常に大規模なチームがある場合に最適。		 マルチリポジトリ環境では、各マイクロアプリを
個別にビルドする必要がある。

他アーキテクチャ

アーキテクチャ名 関係リンク
Modular Monolith ・Deconstructing the Monolith – Shopify Engineering
・kgrzybek/modular-monolith-with-ddd
Enterprise Architecture (Clean Architecture) ・Building an Enterprise Application with Vue
・soloschenko-grigoriy/vue-vuex-ts
Jam Stack Jam Stack
App Shell App Shell モデル

書籍

www.manning.com

参考記事