在开始另一个发布之前等待一个发布完成答案

【问题标题】：Waiting for one publish to finish before starting another在开始另一个发布之前等待一个发布完成
【发布时间】：2025-12-13 00:25:01
【问题描述】：

我还没有找到一个相对好的解决方案。也许社区可以提供帮助？

我正在从一些安静的端点将数据提取到我的流星应用程序中。一个建立在另一个之上。例如..我达到了一个终点并获得了一组作者。然后我需要点击第二个端点来提取每个作者写的书。

现在我在服务器端有两个独立的发布函数来获取数据集，但是第二个依赖于第一个的数据。（我最初在我的应用中尝试只是在一次发布中完成所有操作，但这感觉不是最好的架构）

有没有办法从另一个发布服务器端订阅另一个发布？或者，我可以做一些其他检查方法吗？到目前为止，互联网和堆栈溢出没有产生什么结果。我知道可用的 publishComposite 包..但它们似乎相对笨重，并不一定适用于我正在尝试做的事情。任何建议将不胜感激

【问题讨论】：

我很困惑：你说你有一些 REST API 和发布功能？所以这些是不同的？如果客户端通过 REST API 获取其数据，那么发布者在这里扮演什么角色？
很抱歉给您带来了困惑。我不拥有 REST API，它们不属于我的应用程序。我的应用正在使用来自这两个端点的数据。因此，为了进一步说明我的示例，我的应用程序调用其他方作者端点并获取作者列表..将其保存在集合中..并发布..然后我的应用程序为彼此调用书籍的另一个第三方端点，并将按作者存储书籍。我希望这能澄清我正在尝试做的事情。我可以在一种发布方法中完成所有操作。但如果可能的话，我想将这些问题分开。
好的，这有帮助。 Meteor 客户端订阅一次或两次以获取所有数据是您的意图吗？
其意图是订阅作者发布，并订阅图书发布......想想书籍网格......然后按作者排序......（在所有数据都下来之后当然是从第 3 方端点存储的）自然需要先发生作者发布，然后我们才能在图书发布中使用该数据。
一般来说，我不喜欢客户端连接。根据您的描述，我可能会进行 1 次订阅并合并数据。但这可能会失去书籍的反应性，所以这可能是不可取的。但我认为更大的架构问题是：是什么驱动了作者的 API 调用？如果它是由订阅请求启动的，那感觉很奇怪。我想我会有其他东西来驱动它，甚至可能是一项 cron 工作，这取决于我希望这些列表在远程服务上更改的频率。因此，传入的订阅将获得您已经拥有的集合数据，可能会在以后更新。

标签： javascript performance meteor

【解决方案1】：

我建议采用分而治之的策略。你基本上有 2 个问题要回答：

对于集合，我要进行客户端连接还是服务器端连接？
什么驱动调用远程服务来获取新数据？

我认为您可以单独构建这些部分，并将它们与 db 和 Meteor 的反应性联系在一起。

例如您可以从编写访问远程 REST API 的代码开始。我认为那里的策略是让作者打电话，获取数据，然后打电话给书籍。我会在一个功能中做到这一点，并与承诺捆绑在一起。当书籍数据返回时，将其和作者数据写入各自的集合（如果您还没有该数据），确保外键完好无损。现在您可以将该功能与按钮按下相关联，该部分现在已完成。

接下来，您可以继续收集并发布该数据。正如我所提到的，你必须决定在哪里加入。但是按照标准 Meteor 实践，当数据库中的集合更新时，您的客户端会获取更新的数据。

此时，您可以测试所有内容是否正确存储并在您按下按钮时进行响应式更新。

最后一步是决定是什么驱动 API 调用，以取代按钮推送。正如我在 cmets 中提到的，也许是一项 cron 工作，但也许您的应用程序中还有其他一些事情可以使它更自然。我想您已经知道，发布的危险在于您可能会同时获得 50 个订阅，并且您不想达到 REST API 50x。

【讨论】：

是的..这就是我现在要达到的模式。非常感谢您在谈论此事时提供的帮助。 :)