3 ms·

Take a look at https://www.meteor.com https://www.meteor.com

amelius 12y ago
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 https://meteorhacks.com/does-meteor-scale.html
- killing_time 12y ago
  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 12y ago
    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 12y ago
      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/10 https://www.meteor.com/try/11 https://www.meteor.com/try/11

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 https://meteorhacks.com/does-meteor-scale.html

killing_time 12y ago
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 12y ago
  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 12y ago
    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/10 https://www.meteor.com/try/11 https://www.meteor.com/try/11