BFF大纲

BFF大纲

从单业务单系统场景开始，一个前端应用对一个后端服务。

业务发展起来后，多个前端应用，对一个后端服务。

后端服务越来越复杂，开始拆分多个后端服务。

技术老大发现，为了防止再出现类似问题，把后端服务跟着业务拆分，成为所谓的微服务。

一个系统服务拆成了：订单服务，用户服务，校验服务，媒体服务等等。

又有一个前端应用出现，想要套用全部过多个微服务能力集，做一个新的系统。

这个时候，由于服务都是独立的，且都有成型的产品在跑，只能用一个后端服务来整合多个微服务，再分发给前端。

后端人员与前端关注点不同，微服务可能提供很多很多字段，且后端小伙伴帮助前端小伙伴分离出有用的字段后，统一返回。

但，页面展示以及前端组内的字段定义与后端不匹配等情况，导致后端下发的字段到前端后，需要前端再次整理。

理想情况是，后端梳理字段，前端拿到所需格式直接套用在研发好的UI组件上，可以答复提升效率。

但实际场景是，后端不关注UI，前端不关注微服务。

此时，需要一个既熟悉前端又可以承载服务转发能力的团队或个人处理这个事情，这就应运而生出Backend for frontend这么个事情。

它的作用就是这么的单纯，做桥梁，优化研发效能。

随着后续的发展，渐渐的，BFF承载了更多，比如服务接口聚合、接口字段优化、访问控制、应用缓存、第三方入口等。

但是有个红线，BFF最好是不要碰，那就是直连业务，切记，BFF不碰具体业务，只是一个为服务而服务的存在。