マイクロフロントエンドでパイプに送信される冗長コード

マイクロフロントエンドの私の理解は、彼らが解決する重要な問題は、企業が複数の可能な異なるチームを持ち、大規模なWebアプリケーションを構成するために使用される個々のコンポーネント/スモールアプリで作業するのを支援することです。

ここで解決されている重要な問題は、複数のチームが独立して作業し、大規模なコンポジットを構築できる能力です。問題は、エンドユーザー向けに無駄のないリリースバンドルを用意することではありません。その理解は正しいですか？

大きなWebアプリケーションを作成するために複数のスモールアプリを使用している場合、同じJavascriptライブラリ（Lodashなど）をエンドユーザーのブラウザーに配送する複数のスモールアプリを潜在的に含めることができるというのは本当ですか？個々のベンダーバンドルは、ある程度の重複/冗長コードがユーザーに送信される原因になりますか？

これは、フロントエンドアプリケーションの設計中に心配する必要がある問題ではありませんか？

ここにはトレードオフがあることは絶対に正しいです。ユーザーエクスペリエンスのいくつかの側面をトレードして、より良い開発者エクスペリエンスを得ることができます（これにより、さまざまな方法でユーザーエクスペリエンスが向上する可能性があります）。これは価値がありますか？場合によります。

たとえば、Spotifyはこのアプローチを使用して、UIを分離されたコンポーネント（source）に分割すると思います。各ウィジェットはiframe内に存在するため、独自のライブラリセットなどを持つことができます。これらのウィジェットには、独立したチーム（職域を超えたチーム）によって作業が行われるという独自の組織上の制約があります。これにより、会社全体の標準に同意し、後でこれらの標準を変更することが難しくなります。そのため、マイクロフロントエンドはある程度の柔軟性を維持するのに役立ちます。しかし、このアプローチがなければ、彼らのデスクトップアプリのメモリ消費は少なくなるでしょう。

HTTPキャッシングはあまり役に立ちません。各マイクロフロントエンドは異なるフレームワークバージョンを使用する場合があります。さらに、複製のコストは、データ転送だけでなく、ライブラリを（再）コンパイルし、複製されたデータ構造を保存するクライアント側のコストです。

個人的には、このようなマイクロフロントエンドは有効なアーキテクチャになり得ると思いますが、

• あなたは高度に自律的なチームを持ち、すべてがユーザーインターフェイスで作業し、非常に頻繁なリリース（毎日など）を行う必要がある非常に大規模な組織です。
• UXのパフォーマンス予算にこの重複の余地があるか、製品が優れているためUXは重要ではありません。パフォーマンスは、開発マシンではなく、ローエンドデバイスでテストする必要があることに注意してください。

組織がそれほど大きくない場合、またはチームがもう少し専門的である場合、関係するすべての人（管理、開発者、最終的にはユーザー）が、不必要な重複を回避する共通のビルドおよび展開プロセスを簡単に行える可能性があります。たとえば、UIで作業しているチームが4つしかない場合は、おそらく共通のライブラリセットについて合意するために互いに話し合うことができ、それらの作業を結合アーキテクチャに統合する方法があります。

マイクロフロントエンドは、これらのことの1つであるように思えますが、本当にクールですが、大規模に運用するまでは必要ありません。