BFF是什么？（Best Friend Forever？^_^）
其实是 Backend for Frontend 首字母的缩写，也就是前端的后端。
BFF通过网络协议连接到后端服务。
在微服务架构环境下，也可以是一个微服务。
BFF的技术实现可以多种多样，如，NodeJs、Java、Python、Go等。
BFF承担什么职责？
1、聚合：通过聚合后端多个接口的数据为前端提供所需要的完整数据。
2、裁减：过滤掉对于前端应用无用的数据。比如，去掉一些前端用不到的字段。
我们要时刻不忘遵守最少数据原则，客户端不需要的数据不要提供。
3、适配：根据端的不同提供端特有的数据。如，根据移动端系统或应用的差别，生成不同的分享或跳转链接。
4、验权：负责前端身份与权限认证，会话状态保持等。
5、安全：提供应用层安全层，防止非法请求，保证数据安全。如，用户身份认证，防止CSRF攻击等。
6、解耦：关注点分离（separation of concerns），BFF关注前端用户体验，后端API关注业务领域模型。不应当包含特定或核心的业务逻辑，不应当保存核心业务数据。
7、复用：有助于避免重复开发带来的工作量，也可以节约运维成本。BFF一个重要作用就是聚合不同前端应用的重复代码。当你发现相同业务的不同前端应用，通过API获取到数据后请求多个接口，或转换或过滤了一些响应数据，或都进行了相同的基于结果数据的进一步计算，此时，你需要考虑把这些代码迁移到BFF。
8、控制：BFF应当有能力根据前端应用的性质不同，控制哪些数据应当或不应该提供给哪个应用。
9、统一：BFF可以承担后端到前端数据传输过程中协议不一致，统一协议的角色。如，有的是HTTP[S]，有的是RPC。
10、提效：可以避免一个业务后台对接多个前端应用的困境，也可以避免一个前端应用需要对接多个业务后台的麻烦。
11、分流：可以用于分散用户端的并发请求。
一个完整的BFF应当是什么样的？
除了实现UX需要的基本业务功能数据和操作接口外，一个完整的BFF微服务也应当有监控、降级、熔断、调用链跟踪、A/B发布等等能力。
BFF应当包含数据库的访问吗？
前面已经说了，BFF是后端的前端，既然他不是处于整个系统的底层，他有自己的后端，所以，一般BFF不应当包含数据库的操作。
那对于缓存的操作可以有吗？
我觉得是可以有的。这就要看是否需要在BFF层缓存数据。
可以包含消息队列的操作吗？
我觉得需要尽量避免，理由是BFF应当尽量轻量化。消息队列的操作大多是与核心业务相关的，而核心业务应当后置到更底层。
BFF如何划分？
一种前端应用应当对接一个BFF。一个BFF可以对接多个前端应用，取决于前端应用需求的相似度，如，相同业务不同平台（Android、iOS）的App。划分的基本原则是UX的差异。
一个前端应用尽量对接一个BFF。
BFF应当是前端团队的工作？还是应当是后端团队的工作？
这个问题应当遵循效率的原则。试问一下我们
为什么要切分BFF？
一定是为了解耦和提效。
我觉得可能放在同一个团队，尤其是同一个业务团队，应变能力更快，效率最高。
缺点有哪些？
1、由于在调用链路上又增加了一层，所以，会有网络延迟上的增加。
2、会增加微服务应用的数量，增加运维的难度。
思考问题：
1、什么技术更适合实现BFF？
2、BFF可以包含HTML页面吗？
