还记得一周前我谈到 UX API 的概念吗?或者换句话说,Backend for Frontend 模式似乎解决了 REST-API 驱动的 SPA 中的一个常见问题:资源表示在语义上不知道 UX 需求。

好吧,在与我的同事进一步审议和实验之后,我在这里列出了一些关于这种方法的不太积极的结论。让我解释。

第一

Backend for Frontend 模式在其最纯粹的解释和实现中,倾向于永远耦合 FE 和 BE。更不用说每个渠道(网络、移动、聊天机器人)和每个应用程序最终可能需要一个 BFF。你明白重点了吗?可维护性地狱。

因此,您开始寻找一种解决方案来使您的 API 满足您的 UX 需求,结果发现您最终拥有了另一个单体;一个组件,您可以在其中开始编写所有获取和调整临时逻辑用于具体应用程序的具体通道。我们需要小心。如果它像反模式一样说话并且像反模式一样走路,那么它可能是反模式。

秒

GraphQL。围绕它大惊小怪,我相信这是当之无愧的。但要小心你在哪里以及如何使用它。在我们的案例中,我们正在考虑使用 GraphQL 作为 REST API 的外观,这似乎引发了一些问题:

1. 获取:确实,通过使用 GraphQL,我们解决了资源获取不足(UI 中所需的数据来自各种 REST 资源,因此您必须执行多个 GET)和过度获取(当您只需要几个属性时下载完整的资源)。但是有一个权衡,因为所有 GraphQL 通信都通过 POST 进行隧道传输,其中过滤条件嵌入在正文请求中。这会使所有服务器调用变得更重,并可能导致性能下降。

2. 适应:当你想要实现一个 GraphQL API 时,会出现一个问题,该 API 是 REST Level 3 API 的外立面,这与HATEOAS有关。简而言之,您可能最终不得不在外观 GraphQL API 中复制完整的原始资源网络,即使对于那些不受适应影响的资源也是如此。这是 API 消费者所需要的:我们的 API 驱动的 SPA 依赖于 HATEOAS 来实现资源可发现性,因此需要保留资源之间的所有超媒体链接。

最简单的解决方案

经过几番漫谈和讨论,解决方案一直摆在我们面前。我们正在推动并将我们的单体应用转变为微服务,因此显而易见的方法是构建一个由 REST API 实现的简单 Custom 微服务。

• 这就像一个代理API,它将根据客户端请求实现所有的获取和适配逻辑。

• 可能不会在App之间复用,但肯定可以被同一个App内的channel复用。

• 它有助于通过替代实现来创建用于测试的模拟资源。

我仍然喜欢将此自定义微服务提供的 API 标记为 UX API 的想法。如果只是因为他们在语义上了解 UX 需求,那么如果组件在语义上与 UI 耦合就可以了。

叹...