当方法调用的数据库副作用影响其他客户端时，那些其他客户端如何“等待”？

Question

当客户端调用方法时，会收到针对其集合副作用已完全同步的订阅的ready消息。但是当该方法导致其他客户的订阅发生变化时会发生什么？

我可以等待/产生/阻止客户端的方法调用，直到其他客户的订阅也被更新了吗？

这将是一个很棒的DDP消息，它真的可以帮助我用Meteor构建更大的应用程序。

Answer 1

简短的回答，我很确定，不是。让我们回过头来看看。所以你想要的行为似乎是：

1. 用户A调用Meteor方法。
2. 该方法在服务器上运行。
3. 所有已连接的客户'集合因更改而更新。
4. Meteor验证所有已连接的客户端是否已更新。
5. 用户A（也可能是所有其他客户）也知道每个人都是最新的，并执行他们等待运行的任何代码。

第4步是问题。首先，所有客户都将受限于最慢客户的同步速度;但即使这不是一个问题，大概有些客户可能不再连接，Meteor会向他们发送一个超时的更新。 Meteor如何知道a）所有在任何特定时刻连接的客户，以及b）他们是否都收到订阅更新？

你可以解决这些问题。这是一种方法：强制所有客户端登录，然后使用像users这样的字段和当前时间戳，每秒或10秒更新lastSeen集合的客户端代码。因此，Meteor可以在30秒或之内查询所有用户users的{​​{1}}集合，以获取最近登录的所有登录用户或用户的列表。这满足（a）。然后，您可以让每个客户端在收到lastSeen消息时运行一些代码，让服务器知道它们已同步;一旦服务器收到来自所有客户端的响应，在30秒后超时（或者你查询的时间很长），那么你已经在服务器上成功确认所有客户端都已更新。这满足（b）。此时，Meteor会将文档插入另一个集合，如ready，记录此消息;并且所有客户都将订阅该集合，因此他们都了解它。当用户A最终获得此消息时，用户A的应用程序会在所有连接的客户端更新后执行您想要完成的任何操作。

邋and而复杂？是。而且很慢。可能有一些方法可以简化它或加快速度，例如通过updates和server-side routes via Iron Router传递消息，但基本上你会扭曲Meteor以使其工作方式与预期不同。 Meteor的设计更像Apache，在大多数情况下，单独的客户端彼此没有任何影响。