マイクロ フロントエンドの実践: 効率的で柔軟なフロントエンド アプリケーション アーキテクチャを作成する

---

インターネット業界の急速な発展に伴い、フロントエンド アプリケーションの規模と複雑さも増大しています。この課題に対処するために、ますます多くの企業や開発者が新しいフロントエンド アーキテクチャ モデルを検討し始めています。新興のフロントエンド アーキテクチャ モデルとして、マイクロ フロントエンドは、高いモジュール性、独立した展開、容易な拡張などの特徴により、業界で徐々に話題になっています。この記事では、マイクロフロントエンドの概念、原理、実用化について実践事例を交えて詳しく紹介します。

1. マイクロフロントエンドの概要

マイクロ フロントエンドは、大規模な単一ページ アプリケーションを複数の独立した小さなアプリケーションに分割する技術ソリューションです。それぞれの小さなアプリケーションは独立して開発、展開、実行でき、共通リソース (スタイル、コンポーネントなど) を共有することでアプリケーション間でデータとステータスが同期されます。マイクロ フロントエンドの中心的な考え方は、フロントエンド アプリケーションを独立して保守および展開できる一連のサブアプリケーションに分解することで、開発効率を向上させ、保守コストを削減し、システムの柔軟性と拡張性を確保することです。

2. マイクロフロントエンドのメリット

1. 高度なモジュール化

マイクロ フロントエンドは、大規模なアプリケーションを複数の小さなアプリケーションに分割し、それぞれが特定の機能またはモジュールを担当します。このモジュール設計により、開発者は特定の機能の開発に集中できるようになり、開発効率が向上します。

2. 独立した展開

各マイクロアプリケーションは、アプリケーション全体をモノリシックに展開する必要がなく、独立して展開できます。これにより、導入プロセスが大幅に簡素化され、導入リスクが軽減されます。

3. 拡張が容易

新しい機能を追加する必要がある場合は、既存のコードを変更せずに、新しいマイクロアプリを開発してメイン アプリケーションに統合するだけです。これにより、システムの拡張性が高まります。

4. テクノロジースタックは無関係

マイクロ フロントエンドにより、各マイクロ アプリケーションが異なるテクノロジ スタックを使用できるようになり、チームにテクノロジを選択するためのより広いスペースが提供され、テクノロジ選択のリスクも軽減されます。

5. 独立したアップグレード

特定のマイクロアプリケーションをアップグレードする必要がある場合、他のアプリケーションに影響を与えることなく、そのアプリケーションのみをアップグレードする必要があります。これは、システム全体の安定性と信頼性を維持するのに役立ちます。

3. マイクロフロントエンドの原理

マイクロ フロントエンドの中心原理は、複数の独立したマイクロ アプリケーションをホストするコンテナーを定義することです。このコンテナは、マイクロアプリケーション間の通信とリソース共有の管理を担当します。具体的には、マイクロフロントエンドには主に以下の部分が含まれます。

1. メイン アプリケーション: メイン アプリケーションはシステム全体への入り口であり、各マイクロ アプリケーションのロードと管理を担当します。通常、メイン アプリケーションには、各マイクロ アプリケーションのコンテンツをホストするコンテナ要素が含まれています。さらに、メイン アプリケーションは、ルーティング管理、ステータス管理などのいくつかのインフラストラクチャ サービスも提供する必要があります。

2. マイクロ アプリケーション: マイクロ アプリケーションは、独立して開発、展開、実行できるメイン アプリケーション内のサブアプリケーションです。各マイクロアプリには、アプリのコンテンツをホストするコンテナー要素が含まれています。さらに、マイクロ アプリケーションは、共有リソースや通信など、メイン アプリケーションと対話するためのインターフェイスを提供する必要もあります。

3. 通信メカニズム: マイクロ フロントエンドは、マイクロ アプリケーション間の通信とリソース共有を実現する必要があります。これは通常、通信プロトコルと API の統一セットを定義することによって実現されます。たとえば、カスタム イベントやメッセージ キューなどを使用してマイクロ アプリケーション間の通信を実現したり、Webpack や Rollup などのパッケージ化ツールを使用してリソースの共有や抽出を実現したりできます。

4. マイクロフロントエンドケースのアイデア

以下では、簡単なケースのアイデアを使用して、マイクロ フロントエンド テクノロジを使用して効率的なフロントエンド アプリケーションを構築する方法をシミュレーションします。コース管理、オンライン試験、学習コミュニティなどの複数のサブ機能を含むオンライン教育プラットフォームを開発するとします。このシステムは次の手順で実装できます。

1. 機能モジュールの分割: まず、オンライン教育プラットフォーム全体を、コース管理モジュール、オンライン試験モジュール、学習コミュニティ モジュールなどの複数の独立した機能モジュールに分割する必要があります。各モジュールは、独立したマイクロアプリケーションとして開発および保守できます。

2. 通信プロトコルの設計: さまざまなマイクロ アプリケーション間の通信とリソース共有を実現するには、統一された通信プロトコルと API を設計する必要があります。たとえば、 emit メソッドを定義してカスタム イベントをトリガーし、 on メソッドを定義してカスタム イベントをリッスンすることができます。また、Webpack の CommonsChunkPlugin プラグインは、パブリック リソースの抽出と共有を実現します。

3. メイン アプリケーションの開発: メイン アプリケーションはオンライン教育プラットフォーム全体への入り口であり、各マイクロ アプリケーションの読み込みと管理を担当します。メイン アプリケーションは、各マイクロ アプリケーションのコンテンツを保持し、ルーティング管理やステータス管理などのいくつかのインフラストラクチャ サービスを提供するためのコンテナ要素を提供する必要があります。さらに、メイン アプリケーションは、さまざまなマイクロ アプリケーションとの通信とリソース共有を実装する必要もあります。

4. マイクロ アプリケーションの開発: 各マイクロ アプリケーションは、独立して開発、展開、実行できる独立した機能モジュールです。各マイクロアプリケーションは、アプリケーションのコンテンツを運ぶためのコンテナ要素を提供し、共有リソースや通信など、メイン アプリケーションと対話するためのいくつかのインターフェイスを提供する必要があります。さらに、マイクロアプリケーションは独自のビジネス ロジックとインターフェイス表示を実装する必要もあります。

5. 統合テスト: 各マイクロ アプリケーションの開発が完了したら、システム全体で統合テストを実施して、マイクロ アプリケーション間の通信とリソース共有が適切に機能することを確認する必要があります。さらに、システム全体のパフォーマンスと安定性をテストして最適化する必要もあります。

---

「マイクロフロントエンド実践」

編集者の選択

マイクロサービスがバックエンド システムに柔軟性と保守性をもたらすのと同様に、マイクロフロントエンドはブラウザベースのアプリケーションにも同じ利点をもたらします。それぞれが独自のインターフェイス、ロジック、ストレージ機能を持つ複数の個別のコンポーネントを含むようにプロジェクトを設計でき、これらのコンポーネントを個別に開発し、ブラウザーで組み合わせて使用​​できます。

『マイクロ フロントエンド プラクティス』という本は、マイクロサービス手法をフロントエンド分野に適用する方法を読者にガイドします。この本では、まずマイクロ フロントエンドの核となる設計アイデアを紹介し、その後、電子商取引アプリケーションを自分で作成し、サーバー側の構成やクライアント側の構成など、開発プロセス中のいくつかの実践的な問題に対処します。 、ルーティング、一貫した外観と相互作用の確保、セックスなど。最終的には、アプリケーション コンポーネントを個別に開発するメリットを最大化するチーム ワークフロー パターンについての洞察が得られます。

簡単な紹介

• 複数の独立したアプリケーションを統合されたフロントエンド アプリケーションに結合する

• 異なるフレームワークに基づいたコードを結合する

• ブラウザ側構成、サーバー側構成、およびルーティング

• 効率的な開発チームの実践とプロジェクトのワークフロー

著者について

Michael Geers は、ユーザー インターフェイス関連の開発分野を専門とするソフトウェア開発者です。彼は 10 代の頃からウェブサイト用のソフトウェアを開発してきました。過去数年にわたって、彼は複数の垂直アーキテクチャ プロジェクトに参加し、複数の国際会議で経験を共有し、雑誌に一連の関連記事を発表してきました。現在も https://micro-frontends.org サイトの運営を続けています。

目次

第Ⅰ部分 微前端初体验

第1章 什么是微前端 3

1.1 概览图 4

1.1.1 系统和团队 5

1.1.2 前端 8

1.1.3 前端集成 11

1.1.4 公共话题 13

1.2 微前端解决了哪些问题 14

1.2.1 优化功能开发 14

1.2.2 不再有前端巨石架构 15

1.2.3 适应变化 16

1.2.4 自主的优势 19

1.3 微前端的缺点 21

1.3.1 冗余 21

1.3.2 一致性 21

1.3.3 异质性 22

1.3.4 更多的前端代码 22

1.4 使用微前端的合理时机 23

1.4.1 适合大中型项目 23

1.4.2 在Web应用程序中使用效果最好 23

1.4.3 效率与开销 24

1.4.4 微前端不适用的场景 25

1.4.5 谁在使用微前端 26

1.5 本章小结 26

第2章 我的第一个微前端项目 29

2.1 The Tractor Store简介 30

2.1.1 准备开始 30

2.1.2 运行书中的示例代码 32

2.2 通过链接进行页面跳转 35

2.2.1 数据所有权 35

2.2.2 团队契约 36

2.2.3 如何实现 37

2.2.4 处理URL的变化 40

2.2.5 优点 41

2.2.6 缺点 42

2.2.7 何时使用链接集成技术 42

2.3 通过iframe进行组合 42

2.3.1 如何实现 43

2.3.2 优点 45

2.3.3 缺点 45

2.3.4 何时使用iframe集成技术 46

2.4 内容预告 46

2.5 本章小结 47

第Ⅱ部分 路由、组合与通信

第3章 使用Ajax进行组合与服务端路由 51

3.1 通过Ajax进行组合 52

3.1.1 如何实现 53

3.1.2 样式与脚本的命名空间 55

3.1.3 声明式地加载h-include 59

3.1.4 优点 59

3.1.5 缺点 61

3.1.6 何时使用Ajax集成 62

3.1.7 总结 62

3.2 通过Nginx实现服务端路由 63

3.2.1 如何实现 66

3.2.2 资源的命名空间 69

3.2.3 路由配置的方法 70

3.2.4 基础设施的归属 71

3.2.5 何时应使用单个域名 73

3.3 本章小结 73

第4章 服务端组合 75

4.1 通过Nginx和服务端包含(SSI)进行组合 76

4.1.1 如何实现 77

4.1.2 更少的加载次数 80

4.2 处理不可靠的片段 81

4.2.1 可分离的片段 82

4.2.2 集成Near You片段 83

4.2.3 超时和回退 84

4.2.4 回退内容 86

4.3 深入研究标签的组装性能 87

4.3.1 并行加载 87

4.3.2 嵌套的片段 88

4.3.3 延迟加载 89

4.3.4 首字节时间和流式输出 90

4.4 其他解决方案概述 92

4.4.1 Edge-Side Includes 92

4.4.2 Zalando Tailor 93

4.4.3 Podium 95

4.4.4 哪种方案更适合 102

4.5 服务端组合的优缺点 104

4.5.1 优点 104

4.5.2 缺点 104

4.5.3 使用服务端集成的时机 105

4.6 本章小结 106

第5章 客户端组合 107

5.1 使用Web Component封装微前端 108

5.1.1 如何实现 110

5.1.2 将框架封装在Web Component内 115

5.2 使用Shadow DOM实现样式隔离 117

5.2.1 创建shadow root 117

5.2.2 样式隔离 118

5.2.3 何时使用Shadow DOM 120

5.3 使用Web Component进行组合的优缺点 121

5.3.1 优点 121

5.3.2 缺点 122

5.3.3 使用客户端集成的时机 122

5.4 本章小结 123

第6章 通信模式 125

6.1 用户界面通信 126

6.1.1 父级页面到片段 127

6.1.2 片段到父级页面 131

6.1.3 片段到片段 135

6.1.4 使用Broadcast Channel API发布/订阅 140

6.1.5 UI通信更适合什么场景 142

6.2 其他通信机制 143

6.3 本章小结 148

第7章 客户端路由和应用程序容器 149

7.1 应用程序容器中的扁平化路由 1521

7.2 双层路由的应用程序容器 162

7.3 single-spa元框架的简述 171

7.4 来自统一单页面应用的挑战 178

7.5 本章小结 183

第8章 组合和多端渲染 185

8.1 结合使用服务端和客户端组合 187

8.2 何时适合采用多端组合 195

8.3 本章小结 197

第9章 适合我们项目的架构 199

9.1 复习专业术语 200

9.2 复杂度的比较 206

9.3 是构建网站还是应用程序 208

9.4 选择正确的架构和集成技术 211

9.5 本章小结 216

第Ⅲ部分 如何做到快速、一致、有效

第10章 资源加载 221

10.1 资源引用策略 222

10.2 打包粒度 238

10.3 按需加载 241

10.4 本章小结 242

第11章 至关重要的性能 243

11.1 高性能架构设计 244

11.2 精简并复用vendor库 251

11.3 本章小结 272

第12章 UI设计系统 275

12.1 为什么需要一个设计系统 276

12.2 公用设计系统与自治团队 279

12.3 运行时整合与构建时整合 286

12.4 样式库中的组件：通用与定制 293

12.5 哪些组件应该沉淀到中心化的样式库中 298

12.6 本章小结 303

第13章 团队及职责边界 305

13.1 将系统与团队对齐 306

13.2 知识分享 314

13.3 横向共性问题 317

13.4 技术多样性 319

13.5 本章小结 323

第14章 迁移、本地开发及测试 325

14.1 迁移 326

14.2 本地开发 333

14.3 测试 339

14.4 本章小结 341

序文/序文

私は 20 年の経験を持つ Web 開発者です。この20年間、私は一人で開発するマイクロアントレプレナーシッププロジェクトから、数人で完成させる小さなプロジェクト、そして多くの人々（椅子の数を確実に超える）の協力を得て行う大規模プロジェクトなど、あらゆる規模のプロジェクトに携わってきました。私のダイニングルームのテーブルで）。

2014 年、neuland Büro für Informatik の同僚と私は、百貨店チェーンの e コマース システムの再構築を担当しました。同社の既存の電子商取引システムはパフォーマンスに問題があるだけでなく、非常に複雑な構造をしており、それをベースにした新しい機能の開発には長い時間がかかり、通常はシステムの他の機能に障害が発生します。関連する開発チームの規模が徐々に拡大するにつれて、システムの保守はますます困難になります。顧客は、新しいシステムがより合理的なアーキテクチャを持つことを要求することに加えて、このアーキテクチャに基づいて、異なる開発チームが互いに影響を与えることなく独立して作業できることも望んでいます。この並行開発能力は、情報技術に基づいてビジネスを急速に拡大するという顧客の計画にとって極めて重要です。そのために、私たちは「縦型」のシステムアーキテクチャを選択しました。機能ごとに複数の独立したチームが分割され、各チームがデータベースからフロントエンドのページ表示までのすべての作業を含む特定のビジネスの開発を担当します。このように、各チームが担当する開発部分は独立して自律しており、最終的にはフロントエンド ページ レベルで統合されます。概念的にはフロントエンド統合は簡単そうに見えますが、実際にはフロントエンド統合を効果的に実装するには多くの知識を習得する必要があります。プロジェクトが進行するにつれて、使用するテクノロジーを徐々に改善し、実践から得た多くの経験を集約しました。

一方、他の企業も同様の技術ソリューションを採用しています。ただし、業界ではこのソリューションに対する統一された名前がありません。 Web アプリケーションを完成させるために協力する複数の独立した自律的なチームが直面する課題を理解するために検索エンジンを使用したいときは、常に、自分の意図を適切に説明する適切な検索用語が見つかりません。 2016 年 11 月、ThoughtWorks Technology Radar は、この技術ソリューションを「マイクロ フロントエンド」と名付けました。この用語の登場により、開発コミュニティで一貫した技術アーキテクチャに基づいたベスト プラクティス、テクノロジ、ツールを誰もが共有することが容易になりました。

2017 年の夏、私は時間をかけて実際の経験をいくつかまとめました。使用されているテクノロジーを独立したサンプル プロジェクトに凝縮し、https://micro-frontends.org で公開します。それ以来、状況は少し変わり、学会での講演に招待されたり、多くの雑誌からオファーをいただいたりするようになりました。コミュニティの開発者も Web サイトをさまざまな言語に翻訳します。

最も重要なことは、昨年の初めに、マニング・プレス社のニコールとブライアンが私に声をかけてきたことです。彼らは私に、マイクロ フロントエンドに関する本を書くよう誘ってくれました。招待状を受け取ったときに最初に思ったのは、「とんでもない、私はライターではないのです。私は言葉を読むことさえ好きではありません。聞いたり、コードを書いたり、システムを構築したり、問題を解決したりするほうが好きなのです。」でも、これも一生に一度のチャンスだと思い、よく考え、家族や友人と何度も話し合い、答えを出しました。最後に、私はチャンスを掴んでその申し出を受け入れることにしました。結局のところ、私は表現と精緻化が大好きです。自分の考えを図 (私は図がとても好きです) とコード例の形で本にまとめることも私にとっては挑戦であり、そのプロセス全体で多くのことを学ぶことができます。この本の執筆プロセスを振り返ってみると、私は当初の決定と、この決定の最終成果物、つまり今ご覧いただいている本に非常に満足しています。