前后端分离是主流的趋势，在前后端分离中，人们最大的痛苦莫过于对api的管理和维护：
- 前端找不到某个字段，原因可能是后端删除了该字段，或者重命名了
- 某个返回数值是错误的，可能是计算错误，可能是业务理解错误
- 前端获取不到数据，可能是后端误删了数据库，或者是在部署
- 状态码预期不一样，某个预期可能是服务器错误，却用200返回成功
同时优势也很明显：
- 独立部署，前端可以运行在自己的服务器上，而不受后端上线计划的影响
- 分清职责，后端将view从系统架构中拆分出去，让系统更简洁
- 技术栈独立，分离前，技术选项会有一定限制，如模版引擎等，分离后，只需要保证api是一致即可
- 方便系统演进，一旦前后端都使用自己的技术栈后，切换技术栈会比较容易，后端可以迁移到微服务，前端可以迁移到微前端架构
- 效率的提高，拆分可以降低维护成本
对于这些问题，这是本章需要讨论解决的问题
api与安全
token管理： 表单检验 权限管理
应对api变更
统一api接口服务 api数据模型，前端借助于typescript 一致化处理方式，统一response、data、result的结构 统一接口名的命名
使用mock server 保持数据结构统一，减少api等待时间 [普通的mock，DSL形式的mock,编程时的mock]
服务于前端的后端：BFF
使用BFF的目的可能是：
- 应对多端应用：一方面，对不同的客户端进行特定的业务处理，另一方面集中处理统一逻辑，降低开发成本
- 聚合后端微服务，当一个业务的处理和展示，需要多个后端服务时，可以通过apiGatewat 聚合后端服务，加快应用的响应时间
- dialing第三方api，通过bff作为中介访问第三方api, 按照己方系统逻辑实现自身需要的api，当更换第三方服务，可以不更换api
- 遗留的微服务改造
每个bff都是独立的服务，意味着维护这么多bff不太容易，我们需要考虑：
- 是否需要提供多种接口，使用不同的客户端
- 是否针对某一特定的客户端，进行后端接口优化
- 是否需要第三方提供api
- 是否存在大量的后端服务作为聚合
- 是否需要为客户端进行业务逻辑处理
api Gateway 和 bff的最大区别： api Gateway只用于一个api入口，而bff则是针对不同客户端，拥有各种 api Gateway
