BFF简介
BFF一词来自Sam Newman的一篇博文《Pattern:Backends For Frontends》，指的是服务于前端的后端。提出这个概念的目的是为了解决什么问题呢？从大的方向来说，主要有以下两个方面：
- 随着电子设备的发展，一个系统可能需要同时在各种设备上展示，比如PC、手机、平板等，但是因为多端的展示要求不同，前端对于数据的获取和组装就会有很大差异
- 其实不止多端数据的问题，对于在微服务时代，一个系统根据功能模块划分为了多个服务，各个服务只管自己的数据，但是前端展示层可能需要各个服务的数据组合等。
那么当面业界的解决方案有哪些呢？
- 前端处理：前端需要负责处理多个数据源的聚合和前后数据依赖关系，前端处理起来比较复杂，并且由于经过了多次的外网请求对页面性能也有影响，。
- 网关处理：在网关处对数据进行聚合处理。这种方式不太容易灵活的定制一些聚合或者页面逻辑的处理。
- 后端处理：后端把数据聚合处理后，提供一个 API 给到前端。这样后端的微服务之间会存在横向的调用，而这是后端微服务架构里一般需要极力避免的做法。
针对这样的场景，现在一般会引入 BFF 这一中间层，让前端应用直接和 BFF 通信，BFF 再和后端 API 进行通信，获取数据并且处理完以后返回给前端。这样就能比较好的满足前后端各自的需求。其实从本质上来说是前端面向页面场景和后端面向业务领域之间的矛盾，由 BFF 这层来解决。
业界针对BFF的解决方案抓哟主要有两种模式：
- 一种是后端BFF模式
- 另一种是前端BFF模式
后端BFF模式
后端BFF模式指的是BFF由后端同学负责，这种模式目前最广泛的实践是基于GraphQL搭建的后端BFF方案，具体是：后端将展示字段封装成展示服务，通过GraphQL编排之后暴露给前端使用。
这种模式最大的特性和优势是，当展示字段已经存在的情况下，后端不需要关心前端差异性需求，按需查询的能力由GraphQL支持。这个特性可以很好地应对不同场景存在展示字段差异性这个问题，前端直接基于GraphQL按需查询数据即可，后端不需要变更。同时，借助GraphQL的编排和聚合查询能力，后端可以将逻辑分解在不同的展示服务中，因此在一定程度上能够化解BFF这层的复杂性。
但是基于这种模式，仍然存在几个问题：
- 展示服务颗粒度问题
- 数据图划分问题
- 字段扩散问题
前端BFF模式
这种模式的理念是，前端完全接手BFF的开发工作，实现数据查询的自给自足，大大减少了前后端的协作成本。但是这种模式也存在一些前提条件及弊端，比如较为完备的前端基础设施；前端不仅仅需要关心渲染、还需要了解业务逻辑等。
实践规则
要实现一个BFF框架，不是一件容易的事情，往往会适得其反，一般需要根据业务实际出发，有以下一些建议：
- 分析BFF问题背后是不是存在后端服务设计问题，优先解决后端服务的设计问题。
- 从业务上分析BFF接口的职责，保证接口职责单一。
- 将BFF中业务能力下沉到后端服务。
- 将BFF中需要复用的技术能力抽取成共享库或下沉建立后端服务。
- BFF为前端而生，关注点在提升前端用户体验。
