背景

去年下半年，我在微信书架里加入了许多技术书籍，各种类别的都有，断断续续的读了一部分。

没有计划的阅读，收效甚微。

新年伊始，我准备尝试一下其他方式，比如阅读周。每月抽出1~2个非连续周，完整阅读一本书籍。

这个“玩法”虽然常见且板正，但是有效，已经坚持阅读六个月。

已读完书籍：《架构简洁之道》、《深入浅出的Node.js》、《你不知道的JavaScript（上卷）》、《你不知道的JavaScript（中卷）》、《你不知道的JavaScript（下卷）》、《数据结构与算法JavaScript描述》、《WebKit技术内幕》。

当前阅读周书籍：《前端架构：从入门到微前端》。

架构设计：前后端分离架构

在现今的前端开发方式里，单页面应用与前后端分离是主流的趋势。采用单页面应用框架，也就意味着前后端分离，以及一系列开发模式的改变——代码库分离、独立部署等。

前后端分离

前后端分离，即前后端各自作为一个半自治的技术独立团队，协作开发同一业务功能。统一中的不统一性，便是前后端分离的有趣之处。

为什么选择前后端分离

前端与后端之间，原本就是技术栈近乎独立的两端。只是在传统的Web应用中，使用后端的模板罢了。因此，即使前后端分离了，带来的技术挑战也不大。对于传统的技术团队来说，之所以存在大量的技术挑战是因为，由多页面应用转向了单页面应用。

它带来了一系列的优点：

• 独立部署。前端应用可以独立运行在自己的服务器上，而不受后端上线计划的影响。
• 分清职责。后端将视图层（View）从系统架构中拆分出去，让系统变得更加简洁。
• 技术栈独立。分离之前，技术选型受一定限制，如模板引擎等。分离之后，只要保证API是一致的，前后端之间就会互不影响。
• 方便系统演进。一旦前后端都使用自己的技术栈，转换技术栈就变得相当容易。后端可以迁移到微服务，前端可以迁移到微前端架构。
• 提高效率（相对的）。对于复杂项目而言，拆分可以降低维护成本；而对于简单的项目而言，拆分则会提高维护成本。

前后端分离的开发模式

在不同的软件开发模式下，前后端分离模式也略微有所差异。瀑布模式的前后端分离，仍然是预先制定API的文档，再进行联调。敏捷模式的前后端分离，则是一个业务一个API，每个API单独集成。

两者之间，敏捷模式更能响应变化，瀑布模式更依赖于前期的设计能力。如果是团队内的项目，那么大抵采用的都是敏捷模式，是团队的成员所能接受的。可一旦对接第三方的API和服务，大家想要的就是瀑布模式，让第三方先把API测试好，再提供给团队使用。但是，有时第三方的API也是在开发中的，所以集成的过程可能会相当痛苦——停下手中的工作，及时地响应API变化。

无论哪种方式都需要从业务逻辑出发，从业务的角度出发，Web应用的前后端是一个整体，它们无法独立运行。

这个过程中，我们要做的事情有：

（1）按业务的展示逻辑，确认出待展示的内容。

（2）前后端根据内容，一起细致化每个字段名，直至接口确认完毕。

（3）遇到对接第三接口时，需要往复进行第（2）步。

（4）当各种开发完成时，在测试环境进行集成。

（5）将完整的业务功能交给QA进行测试。

前后端分离的API设计

1、RESTful API

RESTful API，几乎是前后端分离的标准实践。值得注意的是，它并没有明确数据的格式是JSON、XML，只是JSON格式更适合于前端开发。顺带一提，实际上很多自己宣称是RESTful API的后端服务，都不能符合RESTful API的所有要求——毕竟要实现按规范完成太难了。

后端都应该提供靠谱的RESTful API。而前端开发人员作为使用方，是确保后端API规范的又一个环节。为此，作为一个Web开发人员，我们还是应该了解一下相关的基本规范：

• 标准的HTTP动词（又称为HTTP请求方法）。GET、PUT、POST、DELETE、PATCH等，每个动词的用法应该和它的行为一致。
• 状态码。20x、40x、50x等常见的状态码，都应该正确地使用。
• 资源路径。RESTful API中的URL用于代表资源，应该确保资源能遵循相关的规范，例如，/comments/1返回第一条评论，/comments/返回所有的评论。
• 参数处理。如果存在大量的参数，那么我们就需要通过GET带查询字符串（Query String）的方式，或者POST带body的方式来进行传递。如果能统一，那么开发起来也就方便了。

2、API与安全

安全，在哪都是一个重要的话题。对于前端开发来说，也存在一些与安全相关的内容。前端的安全措施能大大地拖延黑客的破解时间。从这种意义上来说，前端安全只处于一个“聊胜于无”的状态——真正的安全措施，都需要毫无保留地在后端实施。

API管理模式：API文档管理方式

当我们拿到一个API文档时，会预期在这个文档里拥有使用API时需要的所有信息。对于SDK类型的API文档，我们预期包含有关函数、类、返回类型、参数等的详细信息，并且还需要附有教程和示例。对于前后端分离项目的API文档，则是预期在API文档中包含有后端URL地址、HTTP请求方法、输入参数、返回参数、返回格式等相关的内容。

API在此时便是一种契约，将不同的团队关联起来，能够让他们高效协作。而文档则是记录这个契约的工具之一。

代码化的方式，它不是普通的代码，而是一份可运行的代码，可以在后端不可用时，提供可供前端使用的API。此外，如果我们愿意，那么只需要补充细节，便可以成为完整的API文档。最重要的是，它可以作为服务使用，并随时修改。

代码化的方式如下：

• HTTP服务即API文档。对于多数互联网应用来说，前端需要的只是一个可运行的HTTP服务，可以在没有后端接口的情况下进行开发。因此，API文档并不是必需的，可运行的HTTP服务才是最重要的。如果只有API文档，前端开发人员还需要自己去创建一个Mock Server，即HTTP服务，来逐一模拟API接口。这时我们可以将HTTP服务当成API文档来使用，这种HTTP服务的形式比较简单，通常由一个个JSON文件构成。
• 代码生成可交互的API文档。它可以提供一个可编辑的在线工具如Swagger，它以代码的方式保存API，还能提供生成HTTP服务的功能。通过编写相应的API文档代码和HTTP服务代码，就可以在网页上直接测试API。

前后端并行开发：Mock Server

Mock Server（仿造服务器），即用于仿造后端接口的模拟HTTP服务器。它是一个简单的HTTP服务，在后端未准备好的情况下，它可以为前端提供一个可用的API服务。在工程实践做得好的项目里，它几乎是前后端分离应用的标准配置。

什么是Mock Server

基于精度考虑，可以用几种不同类型的Mock Server来实现：

• 普通Mock Server。我们在API配置文件中定义了什么，便返回什么内容。其特点是简单、易维护，缺点是不容易模拟所有情况。如果只是简单的页面显示，不涉及复杂的权限逻辑，那么就可以考虑这种类型的Mock Server。
• DSL形式的Mock Server。DSL，即领域特定语言，它是专门针对某一特定问题的计算机语言。这种方式与普通的Mock Server有所不同，其配置文件（通常是JSON）是通过特定格式编写的，返回的数据只是API配置的一部分。在这个文件中，我们还需要登录生成一个Token，根据不同的请求和Token返回不同的内容。相比之下，比较接近于真实的服务，登录完成后获取Token，每次请求的时候都会验证Token。一旦Token不匹配，就返回错误的结果。
• 编程型Mock Server。它需要我们编写简单的代码，才能返回对应的API数据。它的优点是灵活性好，但是缺点是维护成本高。它需要花费一两个小时来编写代码，才能返回对应的数据，这会带来额外的开发成本。这种接口适合于复杂的项目（大部分API需要四五天的时间来实现），如果项目不复杂，那么使用这种类型的Mock Server，则会有画蛇添足的味道。

Mock Server选型指南

三种Mock Server中，选择适合自己项目的Mock Server，倒也是不难了。

• 如果只是前端开发人员用来简化开发，而后端不能提供支持，那么使用普通的JSON Mock Server就可以了。
• 如果前后端同时维护Mock Server，那么可以尝试使用DSL形式的Mock Server，可以提供更多的特性。
• 需要更多的定制化功能，则可以使用编程型Mock Server。

前后端并行开发总结

在有了契约和Mock Server之后，前后端的开发模式变成：

• 前后端约定契约API，并完成对应的Mock Server实现。
• 前后端根据各自的逻辑实现对应的业务代码。
• 前后端编写各种契约测试，并确定API的修改能够反映到持续集成。
• 前后端进行API集成。
• 在API修改时，修正对应的API修改。

服务于前端的后端：BFF

大量的业务逻辑放在后端实现，能在某种程度上降低应用的开发和维护成本。这些与业务相关的处理逻辑，直接放在原有的后端代码中也不是很合适。它们类似于胶水代码，难以整理和维护，并且它们需要经常修改。为了将这些业务代码抽离出来，形成更好的系统架构，便出现了前端、后端之间的中间层，这样的中间层称为BFF。

为什么使用BFF

BFF，即Backends For Frontends（服务于前端的后端），是指在服务器设计API时会考虑客户端的使用情况，在服务端根据不同的设备类型返回不同客户端所需要的结果。BFF模式不会为所有的客户端创建通用的API，而是创建多个BFF服务：一个用于Web前端，另一个用于移动客户端（甚至一个用于iOS，另一个用于Android）。

在不同项目下，使用BFF的意图各有不同。我们使用BFF的目的可能是：

• 应对多端应用。一方面，对不同的客户端进行特定的业务处理；另一方面，集中处理统一逻辑，降低开发成本。
• 聚合后端微服务。当一个业务的处理和展示，需要多个后端服务时，可以通过APIGateway来聚合后端服务，以加快应用响应的速度。
• 代理第三方API。客户端不直接访问第三方API，而是通过BFF作为中介来访问第三方API。同时，按自方系统的逻辑来实现符号自身需要的API。当更换第三方服务时，可以不更换API。
• 遗留系统的微服务化改造。从单体架构迁移至微服务时，先通过BFF来调用单体应用的功能。再逐一创建微服务，当完成一个服务时，将请求指向新的微服务。慢慢地，就可以从遗留代码转移到新的演进方案上。

前后端如何实现BFF

前端开发人员擅长编写JavaScript/TypeScript，所以由Node.js来实现BFF层，几乎是前端的第一选择。前端开发人员可以选择合适的Web框架（如Koa、Express、Egg.js）来打造BFF，也可以使用更合适的GraphQL来完成。

后端开发人员在实现BFF时，出于维护或者组织内部规则，会偏向于使用后端现有的技术栈。前端开发人员按照自己习惯的Ajax/Fetch请求写代码，再按一定的逻辑展示到页面上。

总结

本篇核心内容如下：

• 前后端分离是如何协作进行的。
• 如何进行API的文档管理。
• MockServer是什么以及如何进行选择。
• 采用BFF架构来提升前后端API的开发效率。

作者介绍
非职业「传道授业解惑」的开发者叶一一。
《趣学前端》、《CSS畅想》等系列作者。华夏美食、国漫、古风重度爱好者，刑侦、无限流小说初级玩家。
如果看完文章有所收获，欢迎点赞👍 | 收藏⭐️ | 留言📝。