“前端可以处理、后端也可以处理”的问题

我们经常可以看到“前端可以处理、后端也可以处理”的问题。往往遇到这种问题不是互相PK就是有一方妥协，或者升级处理。难道没有一种标准的方案可以解决吗？

大团队中高级研发或者架构师可以很好的解决这个问题，从架构层面看这件事会有标准答案。但是架构设计中不会考虑到每一个接口每一个字段，很多事只有在执行过程中才会碰到的具体问题。因此，团队中每一位成员都应该能够解决这个问题才行。

前后端视角差异

前后端视角的差异，不站在旁观者的视角是难以体会的。

例如常见的修改表头功能：

在这个场景中，如果前后端对此有争执，最终的结果大概率可能是后端新增2个接口，并且把列表接口的返回值修改为map类型以兼容动态字段。

但对于后端的工作来说，这些都是用户体验的部分，不是业务逻辑核心。这类工作不是后端应该聚焦的地方，是为了用户体验做的额外工作。

前端负责体验，后端负责抽象

前端每天面对的是js，但前端真正需要负责的是用户体验。

上面的场景中，表头能够修改这个功能是用户体验的部分，不是业务核心逻辑。前端应该对所有用户体验相关的工作负责。因此BFF的概念被提了出来，可以用来解决前后端交互问题，定义前后端边界。

BFF

Backend-for-Frontend的优点：

• 分离前后端视角
• 实现对用户体验更好的api，而不是更抽象的api

缺点：

• 应用的复杂度升级，需要更复杂的设计方案。更重，不快速

BFF的边界

bff不是用来解决后端工作量问题，而是用来解决前端的体验问题。

传统前后端交互和微服务体系中bff交互的对比

可以看出bff层是独立于普通后端的一个旁路。和普通后端相比，bff至少有几个特点：

• 一般主要对接后端内部接口，内部接口的最佳实践应该是高性能协议比如grpc
• 基本不参与数据读写
• 不参与业务逻辑，哪怕是最简单的
• 代理接口，但不能做分布式事务相关的操作
• 不能做万能接口

BFF的设计范式

• 每种用户体验一个BFF后端，而不是每个项目必须对应一个或整体使用一个。常见的设计场景例如web一个、app一个
• 使用事件驱动而不是轮询来获取后端接口更新，用更后端的习惯解决问题
• 使用适合的连接方式，不一定非得是rest api，sse/ws都是可用的选项
• 不要涉及业务逻辑，不要让逻辑错误出现在bff中
• 后端内网接口完全符合前端需求的，直接让网关代理，bff无需做转换

BFF开发注意要点

虽然并不限定语言，但BFF就是为了解决前端问题而出现的，前端自己开发是比较合理的。使用公共npm包甚至可以共享dto，代码层面是非常方便的。

常见的node开发注意要点：

• 使用纯ts保持类型校验。虽然现在对ts有很多不同的声音，但是对于团队开发，没什么比类型校验更重要的了。
• 尽量保持对依赖注入的使用。每个模块export interface而不是变量或class或function
• 内部接口全部使用grpc进行对接，保持性能的同时避免字段定义问题
• 注意应用无状态，一个实例和10个应该没有区别
• 关注firstbyte、日志、应用监控、内存占用、gc

有BFF参与的架构设计示例

一个简单的crm模型，有BFF参与后的效果

一个简单的crm模型，只存储了客户和订单2个对象。因此订单和对象抽象成2个中台服务，提供流程无关的接口。

bff负责只读的部分，包括：

• 客户列表
• 客户详情
• 订单列表，其中包括部分客户信息
• 客户旅程，可能包含客户的访问、意向、下单、客服沟通等记录

而后端负责修改的部分，通常都带有事务操作。包括：

• 客户的新增删除
• 下单和订单操作

bff能做的部分后端当然也很容易做，但假如现在来了新的需求，比如：

• 客户列表的导出需要能够导出客户的最近一个订单的地址
• 订单列表可以批量操作发货，但需要校验发货状态后操作才能成功，校验平均耗时1分钟。需要在界面上实时变更状态

可以看出类似这样的需求其实没有变更核心业务逻辑，只是体验上的差异。按照“传统“的做法当然可以实现，但是会造成非业务代码增多，导致系统维护困难。有了BFF层后，这类体验性质的代码都在bff层中做了处理，既不影响核心业务的升级改造，又快速的满足了需求。又好又快

最后

BFF是一种复杂系统微服务环境下设计模式，没有发明什么新技术，利用分工的特点解决了一些问题。系统不复杂的、垂直的、大单体还没有用到微服务的，都不需要引入BFF加入额外的复杂度。

在实际设计中注意BFF的边界问题，一定不要参与到业务逻辑中，哪怕是最简单的也不行，今天的简单不代表明天的简单。

更多精彩内容

内存占用不到20m的cdc工具

今天，让postgre原地起飞-开源postgre列式存储引擎发布

模块化golang工程

研发团队新鲜事儿，就来公众号「迷路idea」找我一起探讨