[amelius]

Thanks for that link. I did a bit of reading, and found this [1].

> These are the main bottlenecks when scaling Meteor, and they introduce two main issues: 1. The polling and comparing logic takes a lot of CPU power and network I/O. 2. After a write operation, there is no way to propagate changes to other Meteor instances in real-time. Changes will only be noticed the next time Meteor polls (~10 seconds).

This seems like quite a limitation. So I wonder if there are any libraries out there that successfully solved this?

[1] https://meteorhacks.com/does-meteor-scale.html

[killing_time]

Specifically about this issue, see the section about the MongoDB oplog further down in the article. This removes the polling interval/overhead, so should significantly improve performance and responsiveness.

[amelius]

Ok. It indeed seems to be the case that the polling delay can be eliminated. But I'm wondering, if db-changes are written to the client directly, is it still possible to apply security rules to that? Evidently, I don't want all my db-changes to be written to all clients, and, preferably, a security-filter should be able to determine which clients receive which updates.

[killing_time]

Yeah - the very earliest preview versions of Meteor had this obvious gap where reads and writes were basically a free for all. However, it's changed a lot since then. As a development crutch the aptly-named 'insecure' package is installed by default (which maintains the free for all), but you're expected to remove it and able to apply fine-grained control to which clients can C/R/U/D which data.

These two steps of the Meteor tutorial probably describe it best: https://www.meteor.com/try/10 https://www.meteor.com/try/11