BFF，既Backend For Frontend。 中文翻译过来的意思是前端的后端。
关于前后端的日常说明：
后端同学要求的服务下沉、解耦、微服务化。 一个消息需要一些接口。 [前端：能帮我组装一下吗？后端：回到你身上，自己努力吧…别人也是这么用的…]
追求前端用户体验[前端：减少一次http请求，多写界面有困难吗？ 后端：不要浪费重写的时间。 这一个请求不错…]
总结：既然前端和后端同学都在说各有道理，那就看看谁有时间处理吧。 那么，有解决这个尴尬场景的解决场景吗？ 那里有BFF。
1.1BFFbff实际上是在前端和后端之间添加中间层。 接下来，用图来看看bff的分布。
BFF层 发挥着 UI适配层和API聚合层，主要是跟进UI的迭代，对后端的接口进行组合、拆分、分化、聚合等。
BFF层下有订单、支付、购物车等多种后端服务，为客户端提供接口，后端为前端提供RPC接口，BFF层提供服务RPC接口
BFF意味着谁用谁开发谁，谁维护谁，谁出事故，前端同学肩负重任，必须从“全栈工程师”开始更进一步。
1.2 BFF的优势主要有以下几个方面
1、可以降低沟通成本，提升前端边界，更加独立。
2、UI多配合，展示不同的数据，灵活配置同一接口，对接口进行添加处理，PC端和移动端可以自由调节字段，同时也可以聚集API减少HTTP要求。
3、提供给第三方api。
4、性能优化、高并发性和负载均衡：一般来说，高并发性性能约束包括大量I/O操作时，CPU利用率较低，而节点在处理I/O负载繁重的操作时具有独特的优势。
5、访问控制可以在BFF层集中控制服务中的权限，使下层服务更加纯粹和独立
6、应用缓存，可以增加缓存中的临时数据，以更快地响应数据。
1.3 BFF的痛点1、重复开发：每台设备开发一个BFF APP应用，将面临重复开发的问题展示，增加开发成本
2、维护问题：需要维护各种BFF APP应用，以前前端也不需要在意并发性，但现在集中在BFF上
3、链接复杂：流程繁琐，引入BFF后，前端、服务端的研发流程必须并行进行，出现很多发布、相互依赖，流程繁琐、浪费
4、浪费资源： BFF层多了，资源占用就成问题，除非灵活扩展，否则会浪费资源
5、分散事务(微服务通病) )。
总结： BFF层并不一定适用，虽然技术有所提高，但也暴露出了相应的问题。 因此，前端想要在BFF中建立中间层，就需要了解更多，同时也剥夺了后端“吃空饷”的一部分。 此后，SSR的出现进一步扩大了BFF层的使用，不利于BFF层，需要看着自己的业务进行选择，目前已经有很多BFF层通过
处理复杂数据的可视化主要以节点图形质量技术堆栈为主。
提高用户体验主要以node SSR技术为主