NestJs 架构问题：将供应商 http 请求与用户驱动的 http 请求分开
NestJs Architecture Question: Separating vendor http requests from user driven http requests
TLDR：
我想确保供应商请求不会阻止应该用于面向用户的请求的网络服务器进程，并且想知道执行此操作的最佳方法。
详情：
我正在构建一个 NestJs 票务应用程序，它聚合来自多个不同第三方票务源的数据，并在我们的网站上向最终用户显示其中的一些数据。
这些第三方 feed 非常大，经常变化，响应速度很慢，并且需要经过一些后端处理才能将相关数据显示给最终用户。因此，我们不会根据用户请求直接访问这些提要，而是不断 运行 数据同步作业，从提要中获取数据并尝试使本地数据库与它们保持同步。这些提要通过 http 进行通信，需要大量请求（每小时 100k+）
同时，我们有一个面向用户的应用程序，每天接收大约 10 万个请求。我想构建应用程序，以确保 运行 网络服务器可以轻松获得面向用户的数据，并且可以处理流量高峰，但也希望将应用程序逻辑保持为一个整体，因为这两个用户面向数据和处理数据共享逻辑，易于开发。
我正在考虑设置一个应用程序实例来处理面向用户的请求，并设置另一个应用程序实例 运行 通过 Nest Queues 进行数据处理工作。我的问题是：
- 这是解决问题的好方法，还是有更好的思考方式？
- 如果这是一个好方法，那么将两者分开以便一个响应用户请求而另一个运行数据处理的最佳方法是什么？我会使用 env 变量来破译当前的 运行 应用程序职责，然后创建适当的 gaurds 等，还是使用其他方式来指导每个应用程序应该做什么？
这是一个自以为是的问题，因此可能不适合 Whosebug。不过，我会在这里留下一些想法。
拥有一个可以通过外部配置具有某些功能 enabled/disabled 的单体应用程序本身并没有什么问题。只需包括打开事物的适当标志。
一个潜在的缺点是，当您 运行 具有不同配置设置的多个实例时，这些实例比它们需要的“更大”（例如 webpack 包大小或 docker 图像大小），但它通常在宏伟的计划中没什么大不了的。
长期的权衡是，您最终会在应用程序内部拥有大量条件逻辑，这可能会让开发人员更难有效地推理、更改和测试。
如果这是我的应用程序，我个人会将其构建为 monorepo，以便您可以将通用功能提取到模块中，然后可以在 API 应用程序和 Worker/Queue 应用程序之间共享.如果您想走这条路，NestJS 在 CLI 中内置了自己的 monorepo support。
或者，您可以查看像 NX monorepos 这样的工具，它也支持模块化方法，让多个应用程序共享逻辑。
您必须评估此处列出的不同方法之间的时间和精力权衡，但如果您发现整体路线最适合您组织的目标，那么请不要怀疑自己。
TLDR： 我想确保供应商请求不会阻止应该用于面向用户的请求的网络服务器进程，并且想知道执行此操作的最佳方法。
详情： 我正在构建一个 NestJs 票务应用程序，它聚合来自多个不同第三方票务源的数据，并在我们的网站上向最终用户显示其中的一些数据。
这些第三方 feed 非常大，经常变化，响应速度很慢，并且需要经过一些后端处理才能将相关数据显示给最终用户。因此，我们不会根据用户请求直接访问这些提要，而是不断 运行 数据同步作业，从提要中获取数据并尝试使本地数据库与它们保持同步。这些提要通过 http 进行通信，需要大量请求（每小时 100k+）
同时，我们有一个面向用户的应用程序，每天接收大约 10 万个请求。我想构建应用程序，以确保 运行 网络服务器可以轻松获得面向用户的数据，并且可以处理流量高峰，但也希望将应用程序逻辑保持为一个整体，因为这两个用户面向数据和处理数据共享逻辑，易于开发。
我正在考虑设置一个应用程序实例来处理面向用户的请求，并设置另一个应用程序实例 运行 通过 Nest Queues 进行数据处理工作。我的问题是：
- 这是解决问题的好方法，还是有更好的思考方式？
- 如果这是一个好方法，那么将两者分开以便一个响应用户请求而另一个运行数据处理的最佳方法是什么？我会使用 env 变量来破译当前的 运行 应用程序职责，然后创建适当的 gaurds 等，还是使用其他方式来指导每个应用程序应该做什么？
这是一个自以为是的问题，因此可能不适合 Whosebug。不过，我会在这里留下一些想法。
拥有一个可以通过外部配置具有某些功能 enabled/disabled 的单体应用程序本身并没有什么问题。只需包括打开事物的适当标志。
一个潜在的缺点是，当您 运行 具有不同配置设置的多个实例时，这些实例比它们需要的“更大”（例如 webpack 包大小或 docker 图像大小），但它通常在宏伟的计划中没什么大不了的。
长期的权衡是，您最终会在应用程序内部拥有大量条件逻辑，这可能会让开发人员更难有效地推理、更改和测试。
如果这是我的应用程序，我个人会将其构建为 monorepo，以便您可以将通用功能提取到模块中，然后可以在 API 应用程序和 Worker/Queue 应用程序之间共享.如果您想走这条路，NestJS 在 CLI 中内置了自己的 monorepo support。
或者，您可以查看像 NX monorepos 这样的工具，它也支持模块化方法，让多个应用程序共享逻辑。
您必须评估此处列出的不同方法之间的时间和精力权衡，但如果您发现整体路线最适合您组织的目标，那么请不要怀疑自己。