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

jopen 8年前

屏幕更小、有限的数据计划和需要更少请求的移动设备的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读者交流群 API后端服务前端的模式介绍 (已满),InfoQ读者交流群(#2) API后端服务前端的模式介绍 )。

来自: http://www.infoq.com/cn/news/2016/01/bff-backend-frontend-pattern