UX API：他们称之为前端的后端

问题空间

我们能做些什么？

哦，那好多了，我的朋友。

我一直在和一位远在地球另一端的同事（我在西班牙，他在悉尼）就现代单页应用程序（SPA）和RESTful API的问题交换邮件和意见。我会尽量长话短说。

问题空间

随着微服务架构方法的普及，我们看到一种趋势，即基于细粒度、对话式的RESTful API来设计系统。这就是构建API驱动的单页应用程序（SPA）。

1. 这些 API 并不符合用户界面需求。就这么简单。它们的设计目的在于暴露业务流程和数据。这才是 API 开发人员真正关心的，而且相信我，用户体验并非 RESTful API 设计流程的一部分。
2. 这意味着我们最终可能会为一个单独的 UI 功能开发多个 API，更糟糕的是，许多 UI 功能可能没有 API 或没有资源表示。
3. 我们无法构建新的 API 或设计新的资源表示，因为这太耗时。因此，前端开发人员最终只能构建高度定制化的解决方案，通过协调大量的 API 调用来模拟所需的资源表示。这会导致代码性能低下或不安全。

因此，UI开发人员需要权衡用户体验和功能需求，才能在他们构建的API驱动型应用程序中兼顾两者。当然，这项工作理应由他们来完成，因为他们精通UI和API两个领域。不用担心，敏捷性一直是这类团队的必备技能。

我们能做些什么？

所以，即使我们都理解问题所在，也可能对解决方案持有不同意见。有人可能会想：“别想着一口气解决所有问题，有些问题是前端解决不了的”，或者“这是组织架构的问题”。我倾向于同意这种观点。构建数字平台意味着很多方面，其中之一是每个人都需要转变思维模式，转向数字化：市场部门需要打造一款只需最终用户极少交互的数字化产品；架构部门需要提供数字化微服务；业务分析师需要转变思维模式，转向数字化；设计师需要意识到，我们不再是2002年了，拥有50个字段的前端可能与数字化产品和架构格格不入。

因此，从组织层面尝试寻找解决方案，一些公司正在设立一个新的角色：数字工程师。这个角色充当之前提到的所有利益相关者之间的联络人。在这个特定的用例中，数字工程师会告知设计师和业务分析师，由于架构中可用的微服务和资源表示方式的限制，他们的工作会受到一些约束。这样可以确保用户体验符合 API 规范，但我并不确定这种限制创造力的做法是否明智。尤其是在强调那些源自流程导向甚至官僚主义的约束（例如数据的表示和公开方式）的情况下。

哦，那好多了，我的朋友。

另一方面，我在悉尼的同事则力主采取更务实的做法。他说：“我知道我们无法改变世界，但我们可以在前端做一些事情，至少让我们的工作更轻松。” 我担心我们会过度设计前端，构建一个一刀切的超级解决方案。但他的观点开始变得有道理：

1. 可用性。80% 的情况下，当我们开始构建前端时，API 尚未准备就绪。我们需要找到一种机制，帮助我们无需等待即可开始开发。
2. 稳定性。我们不能因为数据表示和展示方式的限制，就告诉业务部门他们期望的用户界面和用户体验无法实现。

然后他提出了一种方案，过了一段时间后，我发现它被称为“前端后端模式”。本质上，这意味着我们可以在用户界面中创建一个 RESTful API 的外观，供用户界面调用，从而模拟该特定用户界面的临时后端。

1. 可用性。数据接口在前端开发过程中可用，因为该组件由前端 UI 开发人员实现。这个中间人将为 UI 提供数据和资源的新表示形式。数据还将通过新的 GraphQL 接口公开。这样，我们无需访问多个端点来获取所需数据，因为 UI 开发人员现在只需从新的模式中选择所需的字段即可。
2. 稳定性。BFF 提供了我们所需的 UI 资源模型和数据。这个外观组件会从 API（SoR 数据）获取REST 资源，将其转换为更符合 UI 需求的中间表示形式，并通过新的 GraphQL 接口将其暴露出来，最终映射到视图模型（UI 组件）。所有这些都在前端完成，因此从某种意义上说，这就像拥有了 UX API。是的，我们这里讨论的是前端 API。这也意味着无需在 UI 中实现复杂且性能低下的逻辑，即可从不匹配的 RESTful API 中收集显示所需的数据。

当然，这只是我们对这种模式的解读。有人可能会认为 BFF 是另一个服务器端组件或中间件，但这正是模式的魅力所在：我们可以赋予它我们想要的实现方式。

我们大概会尝试一下这种模式。原因很简单，正如伊恩·罗宾逊在2006年的这篇文章中提到的（唉，这些文章总是经得起时间的考验），API的成功取决于它的使用者：

“消费者驱动型供应商合同的衍生性质，为服务提供商与消费者之间的关系增添了异质性。也就是说，供应商须承担源自其自身边界之外的义务。但这丝毫不影响其实施的根本自主性；它只是明确地表明，服务的成功依赖于其被消费这一事实。 ”

伊恩说得很好，谢谢。

当然，这并非万全之策，每个解决方案都取决于问题的具体情况和背景，因此对某些人来说，采取组织层面的方法可能更容易。正如马丁·福勒所说，这是一篇通用性文章，因此也难免会受到“通用建议谬误”的影响。