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?
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.
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.
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 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