API 后端服务前端的模式介绍

  • Jan Stenberg
  • 陆志伟

2015 年 12 月 31 日

话题:设计模式语言 & 开发架构

屏幕更小、有限的数据计划和需要更少请求的移动设备的 web 体验与桌面浏览器有诸多不同。移动设备需要更少往往也是不同的数据,并且可能提供其它交互,比如通过条形码扫描器。这意味着我们需要在 API 后端添加额外的功能,实现对移动设备的支持,Sam Newman在他的博客文章中如此解释,并描述了API 后端模式,用于处理不同类型用户体验设备之间的不匹配。

Thoughtworks 的开发者 Newman 描述了一种解决方案,构建一个通用的 API 后端,用于所有类型的用户接口。由于非常不同的需求,虽然在实践中这意味着向后端增加功能和复杂性。但是它也可能成为瓶颈,因为需要对支持的所有设备部署所需的所有变更,它会减慢部署过程。当从事通用后端开发时,有时需要创建一个特殊团队,尤其是后端团队,在 Newman 看来,这会增加问题,现在前端团队需要与一个独立的团队进行沟通,同时这个团队还必须优先考虑来自其他团队的需求。

另一种 Newman 已经看到在使用的解决方案是为每个用户体验开发一个 API 后端。从概念上来讲,一个面向用户的应用由两部分组成,一个在客户端,一个在服务端,也就是服务于前端的后端(BFF 这一术语是由 SoundCloud 的Phil Calçado创造的)。

BFF 通常紧密耦合到一个特定的用户接口,二者均由同一个团队维护。当在不同的平台上处理相同类型的用户接口时,比如 Android 和 iOS,Newman 描述了两种方法,一种每个平台一个 BFF,另一种是每种类型的接口一个 BFF。

Newman 更倾向每个平台一个 BFF 这种严格的模型,比如一个用于 Android 和一个用于 iOS。其中值得关注的是这种方法有在 BFF 之间产生大量重复工作而结束的风险,比如相同类型的聚合或者为下游服务接口而产生的相似代码,但是他一点也不担忧这种重复工作,因为它是跨进程壁垒。合并成一个通用的聚焦边缘 API 服务(a general-purpose aggregating Edge API service)是他极力警告和反对的,并指出这种模型已经被一次又一次的证明会导致高度臃肿的代码。

为每个类型的客户端使用一个 BFF,即 Android 和 iOS 共同使用一个 BFF,这种方法他看到 SoundCloud 已经在使用。他对这种方法的顾虑是,随着越来越多类型的客户端,增加了 BFF 臃肿的风险。

同样为 Thoughtworks 工作的Lukasz Plotnicki最近写了一篇博客文章,从一体性 Rails 应用转向使用微服务期间SoundCloud 所做的 BFF 工作

在 Thoughtworks 最新的技术雷达上, BFF被作为一项值得追求的技术而被提及。

查看英文原文A Pattern for API Backends Serving Frontends


感谢张龙对本文的审校。

给 InfoQ 中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ@丁晓昀),微信(微信号:InfoQChina)关注我们,并与我们的编辑和其他读者朋友交流(欢迎加入 InfoQ 读者交流群(已满),InfoQ 读者交流群(#2))。

设计模式语言 & 开发架构