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

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

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

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工作的最近写了一篇博客文章，从一体性Rails应用转向使用微服务期间。

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

查看英文原文：

感谢对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至。也欢迎大家通过新浪微博（，），微信（微信号：）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入InfoQ读者交流群（已满），InfoQ读者交流群（#2））。