API，后端和前端是三个独立的组成部分。

Question

我曾试图在互联网上找到类似的东西，但没有找到。所以我在这里问一下：

情况：我有一个大型API，它进行一些重要的计算并具有很多功能。有一些客户正在使用此API，并已将其实现到他们的软件中。现在我想为该API编写一些前端，以便一些用户可以更轻松地管理他们的工作流程。

考虑的解决方案：我考虑制作一个单独的后端应用程序，它将使用API并为前端提供服务（请查看附加的图片）。后端将执行授权/缓存/数据适配操作。

问题: 但我从未设计过具有三层API-BE-FE的应用程序。那么这样做值得吗？有什么显著的缺点吗？在后端方面放置一些oauth授权，而不是api本身，是否安全？你对此有何想法？

- Laimonas Sutkus

Answer 1

我同意你的设计。你有一个特定的API，旨在为特定的端点提供服务。这样，你可以分离你的关注点，因为你可以添加与API本身无关但与FE相关的BE内容。 此外，许多API正在使用凭据和密钥，因此你可以实现类似的功能。

- Gilad Bar

Answer 2

你对架构的考虑方案看起来很不错。

在前端和API之间实现后端的最大优势是可以提供良好的关注点分离。通常情况下，我周围的前端工程师每次需要新的端点时都会向API工程师询问。这看起来只是合作，但有时会过度。这种对话有可能导致在API中创建太多本不应该存在的端点。我不确定你们公司的API团队的架构政策是什么，但是仅仅为了让API变得更大而允许它增长并不好。现在API拥有的功能越多，它就越容易变得糟糕。

在你的计划中，你正在尝试实现后端以访问API供前端使用。这类似于Sam Newman描述的BFF（面向前端的后端）架构（http://samnewman.io/patterns/architectural/bff/）。通过这个概念，你可以将后端实现为一种网关，处理前端特定的API请求。如果需要，后端甚至可以缓冲前端变化对API的潜在影响。所有东西都可以保持良好的分离。

在BFF中，我认为后端不扮演提供与应用相关的功能（如授权、缓存和数据适配操作）的角色，但这取决于你。你可以实现新的API来处理这些功能，并让后端只作为将它们绑定在一起的网关。只要后端不太臃肿，将这些功能放入后端也是可行的。

缺点？

我想可能的缺点是可扩展性的可维护性。这完全取决于你所合作的基础设施团队或成员，但在生产环境中，API和后端将在每个不同的服务器或堆栈上运行，因此在大量流量下，你可能需要确保它们之间的扩展一致性。然而，这种独立性在监控硬件资源方面也可能有优势。你最好找到一个平衡点。

- IzumiSy