我试图在互联网上找到一些东西，但找不到类似的东西。所以我在这里问：
情况：我有一个很大的 API，它可以进行一些繁重的计算并具有很多功能。有一些客户使用这个 API，并在他们的软件中实现了它。现在我想为该 API 编写一些前端，以便一些用户可以更轻松地管理他们的工作流程。
考虑的解决方案：我正在考虑制作一个单独的后端应用程序，该应用程序将使用 API 并为前端服务（请看附图）。后端会做授权/缓存/数据适配操作。
问题：但我从来没有用三层 API-BE-FE 跨越过这样的应用程序设计。那么这样做值得吗？有什么明显的缺点吗？在后端放置一些oauth授权是否安全，而不是api本身？您对此有何看法？
【问题讨论】：
标签： javascript api http frontend backend
您考虑过的架构解决方案看起来不错。
在前端和 API 之间实现后端的最大优势是，它可以提供良好的关注点分离。我身边经常发生前端工程师每次需要新端点时都会询问 API 工程师。看起来只是合作，但有时太过分了。这种对话有可能导致在 API 中产生过多不应该有的端点。我不太确定你们公司 API 团队的架构策略是什么，但是仅仅让 API 做大做前端是不好的。 API 现在拥有的功能越多，它就越容易变得越糟糕。
在您的计划中，您正在尝试实现后端以访问前端的 API。它类似于 Sam Newman (http://samnewman.io/patterns/architectural/bff/) 描述的 BFF (Back-end For Front-end) 的架构。有了这个概念，您可以将后端实现为一种网关，用于处理前端对 API 的特定请求。如果需要，后端甚至可以缓冲前端更改对 API 造成的潜在影响。一切都可以很好地分开。
在 BFF 中，我不认为后端在提供与应用程序相关的功能（例如授权、缓存和数据适应操作）方面发挥作用，但这取决于您。您可以实现新的 API 来处理这些功能，并让后端只是一个将它们联系起来的网关。只要不太胖，也可以将这些东西放入后端。
我想，可能的缺点是缩放的可维护性。这完全取决于与您合作的基础架构团队或成员，但在生产环境中，API 和后端将在每个不同的服务器或堆栈上运行，因此您可能需要在应用程序的大量流量下注意它们之间的扩展一致性.然而，这种独立性在监控硬件资源方面也可能是有利的。你最好找到一个甜蜜的地方。
【讨论】：
我同意你的设计。您有一个特定的 API，旨在为特定的端点提供服务。这样您就可以分离您的关注点，因为您可以将与 API 本身无关但与 FE 相关的东西添加到您的 BE 中。 此外，许多 API 都使用凭据和密钥，因此您可以实现类似的功能。
【讨论】：