屏幕更小、有限的数据计划和需要更少请求的移动设备的 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））。
评论