Backend for Frontend

在微服务架构中，我们的系统被分解为数十个小型的、集中的服务，例如用户服务、订单服务和产品服务。 但是，在向用户显示此信息时，不同的设备有非常不同的需求。高速台式计算机上的网络浏览器需要一个包含表格、侧边栏和图表的丰富仪表板。慢速蜂窝网络上的移动应用程序需要简单、轻量级的布局来节省带宽和电池。智能手表应用程序可能只需要一行文本。 如果所有这些前端都查询完全相同的后端 API，则必须有人做出妥协。要么移动应用程序被迫下载大量无用的数据，要么网络应用程序被迫发出数十个单独的网络请求来获取所需的所有内容。 这正是 后端为前端 (BFF) 模式 解决的问题。在本指南中，我们将用简单的语言解释此模式，查看现实世界的类比，将其与标准 API 网关进行比较，并逐步完成实际的代码实现。 现实世界的类比：餐厅菜单 想象一家餐厅为三种截然不同类型的食客提供服务： 一位美食评论家想要一份完整的 5 道菜品尝菜单以及详细的成分列表。 忙碌的通勤者想要在火车上吃一份预先包装好的快餐。 一个孩子想要一份简单的儿童餐，份量小，没有辛辣的成分。 如果餐厅只有一份菜单详细列出所有三个选项，那就会让人不知所措。通勤者会浪费时间阅读 5 道菜的食谱，而孩子的父母则很难找到简单的食物选择。 相反，餐厅打印三个自定义菜单：品尝菜单、快速外带菜单和儿童菜单。 每个菜单都来自同一个厨房（微服务），但专门针对该客户（客户端）设置选项的格式和大小。 在这种情况下： 厨房代表您的微服务（用户、目录、付款）。 自定义菜单是您的BFF（Web BFF、移动 BFF、观看 BFF）。 食客是您的前端（桌面浏览器、移动应用程序、智能手表）。 问题：“一刀切”的 API 当微服务第一次流行时，许多团队构建了一个单一的、共享的 API 网关来处理所有前端客户端： 虽然单个入口点很好，但共享 API 引入了几个扩展瓶颈： 移动设备的有效负载膨胀：桌面 Web 应用程序需要用户的订单历史记录、帐单地址、个人资料图片和忠诚度积分。移动应用程序只需显示“最后订单：已发货”。通过共享 API，移动应用程序会下载整个配置文件有效负载，从而浪费宝贵的数据并减慢加载时间。 API 瓶颈：单个团队成为共享网关的瓶颈。如果iOS团队想要改变一个小的布局字段，他们必须等待共享网关团队部署新版本，从而减慢开发周期。 不同的安全需求：Web 浏览器可能需要基于 cookie 的会话来防止跨站点脚本 (XSS)，而移动应用程序更喜欢基于令牌的 OAuth 标头。在单个服务器中处理这两者会产生复杂、混乱的代码。 解决方案：BFF 模式 BFF 模式提倡为 每个前端应用程序构建一个专用后端服务器，而不是为所有设备创建一个巨型网关。