NestJs 架构问题：将供应商 http 请求与用户驱动的 http 请求分开

Question

TLDR： 我想确保供应商请求不会阻止应该用于面向用户的请求的网络服务器进程，并且想知道执行此操作的最佳方法。

详情： 我正在构建一个NestJs 票务应用程序，该应用程序汇总来自多个不同第三方票务源的数据，并在我们的网站上向最终用户显示其中一些数据。

这些第三方提要很大，经常变化，响应速度很慢，需要经过一些后端处理才能将相关数据显示给最终用户。因此，我们不会根据用户请求直接访问这些提要，而是不断运行从提要中获取数据并尝试保持本地数据库与它们同步的数据同步作业。这些提要通过 http 进行通信，需要大量请求（每小时 100k+）

与此同时，我们有一个面向用户的应用程序，每天接收大约 10 万个请求。我想构建应用程序，以确保面向用户的数据可轻松用于正在运行的 Web 服务器并可以处理流量峰值，但也希望将应用程序逻辑保持为一个整体，作为面向用户的数据和处理数据共享逻辑，易于开发。

我正在考虑设置一个应用程序实例来处理面向用户的请求，并设置另一个应用程序实例来通过Nest Queues 运行数据处理工作。我的问题是：

• 这是解决问题的好方法，还是有更好的思考方法？
• 如果这是一个好方法，那么将两者分开以便一个响应用户请求而另一个运行数据处理的最佳方法是什么？我会使用 env 变量来破译当前运行的应用程序职责，然后创建适当的 gaurd 等，还是以其他方式指导每个应用程序应该做什么？

Answer 1

这是一个自以为是的问题，因此可能不适合 StackOverflow。不过，我会在这里留下一些想法。

拥有一个可以通过外部配置启用/禁用某些功能的单体应用程序本身并没有什么问题。只需包含打开的相应标志即可。

一个潜在的缺点是，当您使用不同的配置设置运行多个实例时，这些实例比它们需要的“更大”（例如 webpack 包大小或 docker 图像大小），但在总体方案中通常不是什么大问题东西。

从长远来看，您最终会在应用程序中使用大量条件逻辑，这可能会让开发人员更难以有效地推理、更改和测试。

如果这是我的应用程序，我会亲自将事物构建为 monorepo，以便您可以将通用功能提取到模块中，然后可以在 API 应用程序和 Worker/Queue 应用程序之间共享。如果你想走这条路，NestJS 有自己的 monorepo support 内置在 CLI 中。

或者，您可以查看NX monorepos 之类的工具，它还支持模块化方法，让多个应用程序具有共享逻辑。

您必须评估此处概述的不同方法之间的时间和精力权衡，但如果您发现采用单一路线最适合您的组织的目标，那么请不要怀疑自己。