前端架构设计全套实施手册，从架构规范、架构设计到微前端架构拆分，助力大前端时代前端架构设计选型和开发，狼叔等众前端专家力荐，前端的复杂性和可预期的未来决定前端需要更多架构师。
★这是一本围绕前端架构的全套实施手册
★架构规范、前端架构设计及微前端架构拆分
★引入6种微前端的概念，以及如何划分、设计微前端应用
★深入探讨规范、原则、模式、架构
★提出了更新、迁移、重构、重写、重新架构等架构演进方式
★从0到1演示如何成为优秀前端开发工程师（初中级）
★助力读者构建更易于维护的系统架构
★作者著书三本，还是七本有关物联网和前端开发书籍的技术审阅者。
★通读本书，让前端负责所有的业务开发成为可能！
★大前端时代前端架构选型和开发不再迷茫！
《前端架构：从入门到微前端》是一本围绕前端架构的实施手册，从基础的架构规范，到如何设计前端架构，再到采用微前端架构拆分复杂的前端应用。本书通过系统地介绍前端架构世界的方方面面，来帮助前端工程师更好地进行系统设计。
前端架构包含以下五部分内容。
设计：讲述了架构设计的模式，以及设计和制定前端工作流。
基础：通过深入构建系统、单页面应用原理、前端知识体系等，来构建出完整的前端应用架构体系。
实施：通过与代码结构的方式，介绍如何在企业级应用中实施组件化架构、设计系统和前后端分离架构。
微前端：引入6种微前端的概念，以及如何划分、设计微前端应用，并展示了如何实现这6种微前端架构。
演进：提出更新、迁移、重构、重写、重新架构等架构演进方式，来帮助开发人员更好地设计演进式架构。
《前端架构：从入门到微前端》适合想要成为优秀前端开发工程师（初中级），或致力于构建更易于维护的系统架构的开发人员、技术主管、软件架构师和软件项目经理等。
1.5 前端架构设计：层次设计
从笔者的角度来看，架构设计本身是分层级的，面向不同级别的人时所展示的内容也是不一样的。如我们作为一个架构师、技术人员，在面对同一级别、更高一级别的架构师、技术人员时，说的便是形而上学的东西，如微前端、前后端分离等各种概念。这些概念，对于接触过相关知识的程序员而言很容易理解。而当我们面对经验略微丰富的程序员的时候，说的可就不是：去实现微前端这样的东西，而是需要落实到怎样去做这样的一件事。
不同阶段构成架构的因素是不同的，基于这个思路，架构设计可以分为四个层级，相应的层级解释如下：
◎ 系统级，即应用在整个系统内的关系，如与后台服务如何通信，与第三方系统如何集成。
◎ 应用级，即应用外部的整体架构，如多个应用之间如何共享组件、如何通信等。
◎ 模块级，即应用内部的模块架构，如代码的模块化、数据和状态的管理等。
◎ 代码级，即从基础设施来保障架构实施。
在设计的时候，既要用自上而下的方式来设计架构，又要用自下而上的方式来完善架构。从演进式设计的角度来看，我们需要在前期设计的时候，对所有系统级架构及部分应用级架构进行技术决策，而其余部分的架构则可以在实施的过程中考虑。
1.5.1 系统内架构
在设计前端架构的时候，首先考虑的是应用在整个系统中的位置——它与系统中的其他子系统是怎样的。这种关系包含了架构和业务上的关系，以及它们之间的协作机制。对于前端应用来说，这一部分的子系统包含了如下两方面内容：
◎ 其他前端应用。关注如何与这些应用进行交互、通信等。
◎ 对接的后台服务。关注如何与后台服务进行通信，诸如权限、授权、API管理等。
如果是系统间的数据通信（如与后台服务之间的交互），那么只需要规定数据通信、数据传递的机制即可。这一类的通信机制，不仅包含了前后端分离架构的API设计，还包含了各类的数据传递，如OAuth跳转的Token验证等。此外，对于传统的多页面应用来说，也需要关注其中的数据传递，如将Cookie作为用户凭据等。
因此，对于前端与后端的关系，我们所要考虑的主要因素是前后端分离架构的设计。
前后端分离架构其实是一个笼统的概念，它是指前后端分离如何实施的技术决策。它包含了一系列的决策、用户鉴权、API接口管理与设计、API（契约）文档管理、Mock Server使用、BFF（服务于前端的后端）、是否需要服务端渲染等。与此同时，当我们开发应用的时候，所涉及的并不只是我们所在团队的工作，往往还需要与其他团队，或者团队内的其他成员的沟通，才能与后端一起设计出整个前后端分离的方案。
当在一个系统内时，微前端是一个应用间的架构方案，当在多个应用间时，微前端则是一种系统间的架构方案。
微前端是将多个前端应用以某种形式结合到一起，当系统中存在多个前端应用（或者单个前端应用的模块较大）时，就需要考虑使用微前端的方式来拆分。此外，还需要做一系列的技术决策来支持应用的整合。
然后，我们还需要考虑前端的客户端展现形式。在大前端的背景下，它可能是PC Web应用、移动Web应用、混合移动应用（结合Cordova构架）、混合桌面应用（结合Electron框架）、原生移动应用（结合React Native）等，具体选择哪一种技术，取决于我们先前调查的利益相关者的需求。当我们做完上述三个核心的架构决策之后，就需要考虑应用的部署架构了。有的客户端形式可能需要服务端渲染，会在某种程度上影响到前端应用的部署，但是总的影响并不大，往往只需要通过反向代理的配置就可以完成部署的配置。如果与后台服务不在一个域，则需要考虑支持跨域请求，或者让后台做一层代码。
有了这些基本的架构设定，便可以继续设计下一层级的应用架构。
1.5.2 应用级架构
应用级架构指的是，单个应用与外部应用的关系，如微服务架构下的多个应用的协作。它可以是一个团队下的多个前端应用，也可以是一个组织内的前端应用。其在组织中所处的位置，也进一步决定了我们所需要设计的架构方案。
若是从相关的定义来看，它与系统级应用存在一定的交集。但是，笔者将其视为系统级架构的进一步细化。比如，在系统架构的层级里，我们定义了微前端架构，而具体的实施细则则会放在各个应用中实现。至于应用间的数据如何交换，不同的应用有不同的实现方式，通常是通过在相应的层级里定义相应的接口来实现。
由于各应用之间需要通过复用代码、共享组件库、统一设计等减少工作量，因此，我们要考虑以下几方面内容。
脚手架。作为一个基础的模块应用，脚手架用于快速生成、搭建前端应用。它除了包含一个前端项目所需要的要素，还包含着与组织内部相关的规范和模式，如部署模板、构建系统等。团队内的多个应用之间往往会使用同一套构建系统，该构建系统会包含在脚手架中。除了包含一系列的构建脚本，它还可以包含编写好的统一的CLI工具。比如在笔者曾经历的混合应用开发的项目里，就曾经通过编写CLI工具支持多个应用的开发。
模式库。它是一系列可复用代码的合集，如前端组件、通用的工具函数等。其作用是在多个应用之间共享代码，降低修改成本。在设计架构的时候，如果考虑内建相应的UI组件库，就需要考虑结合装饰器模式，将模式库作为一层代理来封装外部的API，以降低后期的修改成本。模式库还包含了用于多个前端应用通信的数据通信库。
设计系统。它相当于更高级别的UI组件库，在这个层级里，我们关注抽象通用的UI模式，用于在多个系统之间共享设计。与模式库/组件库不同，设计系统偏向于设计人员的模式，而非开发人员的视角。
在应用级架构中，我们将决定选择哪种前端框架，并进行相关的技术选型。
1.5.3 模块级架构
模块级架构是深入单个应用内部、更细致地设计应用内部的架构，它所涉及的内容是我们在日常开发中经常接触的。我们所要做的是，制定一些规范或者更细致的架构设计。这部分内容会在我们开始业务编码之前进行设计。在敏捷软件开发中，它被称为迭代0/Sprint 0/Iteration 0，其相关的内容有以下两个方面：
◎ 模块化。它包含了CSS、JavaScript、HTML/模板的模块化。对于JavaScript或者模板而言，其模块化的设计受框架的影响比较深。对于CSS来说，我们也需要设计一个合理的方式来进行管理，既需要考虑全局样式以用于样式复用、局部样式以用于隔离变化、通用变量以方便修改，又需要考虑相应的工具来辅助设计。此外，还需要定义相应的CSS、JavaScript、模块的代码组织方式。
◎ 组件化。它主要考虑的是，在应用内如何对组件进行封闭，以及相应的原则和粒度。
此外，对于不同的框架，还涉及一些框架特定的模式与架构设计，它们会在一定程度上影响单个应用的架构。对于不同的框架来说，所涉及的范围有所不同。如在Angular框架中，不需要关心相关的模式，只需要掌握框架定义的规范即可，如使用Service来保存应用的状态、使用Pipe来处理数据等。而在React框架中，则需要设计状态和数据流的管理方式，即需要诸如Flux或者Redux这样的状态管理方案。
1.5.4 代码级：规范与原
……………………
第1章 前端架构 1
1.1 为什么需要软件架构 2
1.1.1 什么是软件架构 2
1.1.2 开发人员需要怎样的软件架构 3
1.2 架构的设计 4
1.2.1 收集架构需求 5
1.2.2 架构模式 10
1.2.3 架构设计方法 11
1.2.4 生成架构产出物 15
1.3 架构设计原则 16
1.3.1 不多也不少 16
1.3.2 演进式 17
1.3.3 持续性 19
1.4 前端架构发展史 20
1.5 前端架构设计：层次设计 21
1.5.1 系统内架构 22
1.5.2 应用级架构 23
1.5.3 模块级架构 24
1.5.4 代码级：规范与原则 25
1.6 小结 25
第2章 项目中的技术架构实施 27
2.1 技术负责人与架构 28
2.2 技术准备期：探索技术架构 30
2.2.1 架构设计 30
2.2.2 概念验证：架构的原型证明 30
2.2.3 迭代0：搭建完整环境 31
2.2.4 示例项目代码：体现规范与原则 32
2.3 业务回补期：应对第一次Deadline 33
2.3.1 追补业务 33
2.3.2 测试：实践测试策略 34
2.3.3 上线准备 35
2.3.4 第一次部署：验证部署架构 35
2.3.5 提升团队能力 36
2.4 成长优化期：技术债务与演进 39
2.4.1 偿还技术债务 40
2.4.2 优化开发体验 41
2.4.3 带来技术挑战 41
2.4.4 架构完善及演进 42
2.5 小结 43
第3章 架构基础：工作流设计 44
3.1 代码之旅：基础规范 45
3.2 代码组织决定应用架构 47
3.3 统一代码风格，避免架构腐烂 49
3.4 使用Lint规范代码 50
3.5 规范化命名，提升可读性 51
3.5.1 命名法 51
3.5.2 CSS及其预处理器命名规则 52
3.5.3 组件命名规则 53
3.6 规范开发工具，提升开发效率 54
3.7 项目的文档化：README搭建指南 55
3.8 绘制架构图：减少沟通成本 56
3.8.1 代码生成 56
3.8.2 专业工具 57
3.8.3 软件附带工具 57
3.8.4 在线工具 58
3.9 可编辑文档库：提升协作性 59
3.10 记录架构决策：轻量级架构决策记录 59
3.11 可视化文档：注重代码的可读性 60
3.12 看板工具：统一管理业务知识 62
3.13 提交信息：每次代码提交文档化 63
3.13.1 项目方式 63
3.13.2 开源项目方式 64
3.13.3 对比不同文档方式 65
3.14 通过流程化提高代码质量 66
3.14.1 代码预处理 67
3.14.2 手动检视代码 69
3.15 使用工具提升代码质量 70
3.15.1 代码扫描工具 70
3.15.2 IDE 快速重构 71
3.16 测试策略 72
3.16.1 单元测试 73
3.16.2 组件测试 75
3.16.3 契约/接口测试 76
3.17 小结 77
第4章 架构基础：设计构建流 78
4.1 依赖管理工具 81
4.2 软件包源管理 83
4.3 前端代码的打包 88
4.4 设计构建流 89
4.5 持续交付问题 99
4.6 小结 105
第5章 架构设计：多页面应用 107
5.1 为什么不需要单页面应用 108
5.1.1 构建成本 108
5.1.2 学习成本 109
5.1.3 后台渲染成本 110
5.1.4 应用架构的复杂性 111
5.2 简单多页面应用的开发 112
5.2.1 选择UI库及框架 113
5.2.2 jQuery和Bootstrap仍然好用 113
5.2.3 不使用框架：You Don’t Need xxx 114
5.3 复杂多页面应用的开发 115
5.3.1 模板与模板引擎原理 115
5.3.2 基于字符串的模板引擎设计 116
5.3.3 基于JavaScript的模板引擎设计 117
5.3.4 双向绑定原理及实践 120
5.3.5 前端路由原理及实践 124
5.3.6 两种路由类型 124
5.3.7 自造Hash路由管理器 125
5.4 避免散弹式架构 127
5.4.1 散弹式架构应用 127
5.4.2 如何降低散弹性架构的出现频率 128
5.5 小结 130
第6章 架构设计：单页面应用 131
6.1 前端MV*原理 132
6.2 前端MVC架构原理 133
6.3 进阶：设计双向绑定的MVC 135
6.4 前端框架选型 138
6.4.1 选型考虑因素 139
6.4.2 框架类型：大而全还是小而美 140
6.4.3 框架：React 142
6.4.4 框架：Angular 143
6.4.5 框架：Vue 145
6.4.6 选型总结 146
6.5 启动前端应用 146
6.5.1 创建应用脚手架 147
6.5.2 构建组件库 148
6.5.3 考虑浏览器的支持范围 150
6.6 服务端渲染 155
6.6.1 非JavaScript语言的同构渲染 155
6.6.2 基于JavaScript语言的同构渲染 157
6.6.3 预渲染 158
6.7 小结 159
第7章 架构设计：组件化架构 161
7.1 前端的组件化架构 161
7.2 基础：风格指南 163
7.2.1 原则与模式 163
7.2.2 色彩 165
7.2.3 文字排印 167
7.2.4 布局 168
7.2.5 组件 173
7.2.6 文档及其他 174
7.2.7 维护风格指南 174
7.3 重用：模式库 175
7.3.1 组件库 176
7.3.2 组件类型 178
7.3.3 隔离：二次封装 183
7.4 进阶：设计系统 184
7.4.1 设立原则，创建模式 186
7.4.2 原子设计 188
7.4.3 维护与文档 191
7.5 跨框架组件化 192
7.5.1 框架间互相调用：Web Components 192
7.5.2 跨平台模式库 193
7.6 小结 194
第8章 架构设计：前后端分离架构 195
8.1 前后端分离 196
8.1.1 为什么选择前后端分离 196
8.1.2 前后端分离的开发模式 197
8.1.3 前后端分离的API设计 198
8.2 API管理模式：API文档管理方式 202
8.3 前后端并行开发：Mock Server 205
8.3.1 什么是Mock Server 205
8.3.2 三种类型Mock Server的比较 207
8.3.3 Mock Server的测试：契约测试 212
8.3.4 前后端并行开发总结 217
8.4 服务于前端的后端：BFF 218
8.4.1 为什么使用BFF 218
8.4.2 前后端如何实现BFF 221
8.4.3 使用GraphQL作为BFF 223
8.5 小结 228
第9章 架构设计：微前端架构 229
9.1 微前端 230
9.1.1 微前端架构 230
9.1.2 为什么需要微前端 232
9.2 微前端的技术拆分方式 234
9.2.1 路由分发式 235
9.2.2 前端微服务化 236
9.2.3 组合式集成：微应用化 237
9.2.4 微件化 238
9.2.5 前端容器：iframe 239
9.2.6 结合Web Components构建 240
9.3 微前端的业务划分方式 241
9.3.1 按照业务拆分 242
9.3.2 按照权限拆分 243
9.3.3 按照变更的频率拆分 243
9.3.4 按照组织结构拆分 244
9.3.5 跟随后端微服务拆分 244
9.3.6 DDD与事件风暴 245
9.4 微前端的架构设计 245
9.4.1 构建基础设施 246
9.4.2 提取组件与模式库 246
9.4.3 应用通信机制 247
9.4.4 数据管理 248
9.4.5 专用的构建系统 249
9.5 微前端的架构模式 249
9.5.1 基座模式 250
9.5.2 自组织模式 251
9.6 微前端的设计理念 252
9.6.1 中心化：应用注册表 252
9.6.2 标识化应用 253
9.6.3 生命周期 253
9.6.4 高内聚，低耦合 254
9.7 “微”害架构 254
9.7.1 微架构 256
9.7.2 架构的演进 256
9.7.3 微架构带来的问题 257
9.7.4 解决方式：可拆分式微架构 259
9.8 小结 259
第10章 微前端实战 261
10.1 遗留系统：路由分发 262
10.1.1 路由分发式微前端 263
10.1.2 路由分发的测试 264
10.2 遗留系统微前端：使用iframe作为容器 266
10.3 微应用化 266
10.3.1 微应用化 267
10.3.2 架构实施 269
10.3.3 测试策略 271
10.4 前端微服务化 272
10.4.1 微服务化设计方案 273
10.4.2 通用型前端微服务化：Single-SPA 276
10.4.3 定制型前端微服务化：Mooa 279
10.4.4 前端微服务化总结 283
10.5 组件化微前端：微件化 283
10.5.1 运行时编译微件化：动态组件渲染 284
10.5.2 预编译微件化 287
10.6 面向未来：Web Components 288
10.6.1 Web Components 289
10.6.2 纯Web Components方式 291
10.6.3 结合Web Components方式 293
10.7 小结 295
第11章 架构演进：演进式架构 297
11.1 更新 298
11.1.1 依赖和框架版本升级 299
11.1.2 语言版本升级 300
11.1.3 遗留系统重搭 300
11.2 迁移 301
11.2.1 架构迁移的模式 302
11.2.2 迁移方式：微前端 303
11.2.3 迁移方式：寻找容器 303
11.3 重构 304
11.3.1 架构重构 304
11.3.2 组件提取、函数提取、样式提取 305
11.3.3 引入新技术 306
11.4 重写 307
11.4.1 重写能解决问题吗 308
11.4.2 梳理业务 309
11.4.3 沉淀新架构 310
11.5 重新架构 311
11.5.1 重搭架构 311
11.5.2 增量改写 312
11.6 小结 313
在2014年左右，三大框架崛起，外加2009年Node.js补齐了服务器端的JavaScript能力，使得工程化、跨端、全栈变为可能，尤其是Weex/RN出现之后，大前端覆盖了移动端等更大范围。随着Node.js在BFF领域遍地开花，我们对未来有了更多的思考，比如Node FAAS的实现，让前端负责所有的业务开发成为可能。前端的复杂性和可预期的未来，决定了前端会需要更多架构师。这本书融合了作者在ThoughtWorks及开源领域的理解，能够很好地给大家构建成体系的前端架构，为想成为架构师的有志青年引路。它未必完全主流，但值得一读。
——《狼书：更了不起的Node.js》作者、Node布道师 狼叔（网名 i5ting）
很多前端工程师过于聚焦“库”和“框架”，缺乏更宏观的对于项目的技术架构，当项目规模急速膨胀后，开发维护成本飙升，陷入泥潭。本书作者黄峰达拥有多年的一线开发和架构经验，作为技术负责人成功地完成了多个大型企业级项目，并总结出一套适应前端的架构，包括团队协作、技术架构等，是值得前端开发人员参考的好书。本书就像一本菜谱，指导你进行食材的选择、加工、调味、摆盘、上菜等，帮你成为一流大厨。
——ThoughtWorks 高级咨询师 刘宇
随着前端日新月异的发展，技术架构越来越重要。《前端架构：从入门到微前端》系统地介绍了不同业务形态下的前端架构，并通过大量的实践代码，帮助我们深入理解了前端架构的基础，以及微前端架构的优势。本书非常适合作为前端技术架构选型时的参考，通过应用微前端架构对遗留系统进行迁移聚合，实现跨团队的并行开发。
——《TypeScript 入门教程》作者 xcatliu
从1995年JavaScript发布到现在，已经有20余年了，如今前端开发的难度和复杂度也越来越高。当我们谈论到“架构”时，也早已不再局限于后端了。黄峰达的这本前端架构书从原理到实践，全面讲解了关于前端的架构。不论你是前端开发者，还是前端负责人，或者是技术遇到瓶颈的高级前端工程师，强烈建议你阅读本书。
——知名前端专家、卓朗数据平台技术总监 justjavac（迷渡）
微前端的概念慢慢地被越来越多的人所了解，大多数中台业务也需要这样一种架构模式。如果你所在的业务也在做相关的事情，那么本书对于业务或者框架开发都是有极大帮助的。黄峰达不仅涉猎前端开发，对后端和设计模式也有着广泛的了解。当你阅读本书时，你会发现它对前端架构的选型和开发都是非常有益的。
——阿里巴巴前端工程师 孙辉