<

Micro Frontends を調べたすべて

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

https://github.com/silverbirder/think-micro-frontends

発端

https://www.thoughtworks.com/radar/techniques/micro-frontends

実績企業

  • Airbnb
  • Allegro
  • Amazon
  • Beamery
  • Bit.dev
  • BuzzFeed
  • CircleCI
  • DAZN
  • Elsevier
  • Entando
  • Facebook
  • Fiverr
  • Hello Fresh
  • IKEA
  • Klarna
  • Microsoft
  • Open Table
  • OpenMRS
  • Otto
  • Paypal
  • SAP
  • Sixt
  • Skyscanner
  • Smapiot
  • Spotify
  • Starbucks
  • Thalia
  • Upwork
  • Zalando
  • ZEISS

ProsCons

Pros

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

Cons

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

統合パターン

https://bluesoft.com/micro-frontends-the-missing-piece-of-the-puzzle-in-feature-teams/

統合選択基準技術
サーバーサイド統合良好な読み込みパフォーマンスと検索エンジンのランキングがプロジェクトの優先事項であること・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

機能

コミュニケーション

https://developer.mozilla.org/ja/docs/Web/API/CustomEvent

https://github.com/postaljs/postal.js

データ共有

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

モジュール共有

  • webpack

https://webpack.js.org/concepts/module-federation/

https://webpack.js.org/configuration/externals/

https://webpack.js.org/plugins/dll-plugin/

ルーティング

Vaddin router

https://vaadin.com/router

キャッシュ

https://developer.mozilla.org/ja/docs/Web/API/Service_Worker_API

https://developer.mozilla.org/ja/docs/Web/API/IndexedDB_API

認証

  • JWT

https://jwt.io/

計測

  • Google Analytics
  • Navigation Timing API
  • Resource Timing API
  • High Resolution Time API
  • User Timing API
  • Frame Timing API
  • Server Timing API
  • Performance Observer

Real User Monitoring

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

Synthetics Monitoring

  • Lighthouse
  • WebpageTest

Proxy

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

https://github.com/tes/compoxure

アクセス履歴

https://developer.mozilla.org/ja/docs/Web/API/History_API

分割ポリシー

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

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

Web サイト ⇔Web アプリ

Microfrontends: An approach to building Scalable Web Apps
Microfrontends: An approach to building Scalable Web Apps

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

リポジトリ

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

他アーキテクチャ

アーキテクチャ名関係リンク
Modular MonolithDeconstructing 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 StackJam Stack
App ShellApp Shell モデル

書籍

https://www.manning.com/books/micro-frontends-in-action

参考記事

役立ったら、☕でサポートしてね!

シェアしよう

関連するタグ