If I look at my application I barely have batch inserts (except for the occasional database schema migration). All of my collections have at least one reactive publication and all of them have publications by simple mongo id and more complex ones. In this scenario (which I believe is pretty typical for Meteor applications), would there still be a benefit?
This is where it actually shines, when you publish by id or $in: ids. It will push to different channels and it will only be aware of modifications for those id or ids. This is already implemented it’s called the “direct-channels” or “dedicated” approach. This is the fastest way to listen to changes.
Let’s say you have a subscription to a simple publication purely by ID and a more complex one that also matches the same record as the simple one. The total amount of messages that Meteor needs to process is now larger if you update a record in that collection?
Meteor will process it twice, (very fast) for the dedicated one, but for the more complex one, it will still need to see if it matches the complex query, especially cases with limit,sort, skip.
Does the fact that you have multiple channels mean the updates can now arrive out of sync?
I mean if you have 2 update operations going in, they might get send to other clients out of order?
Yes it might I need to study redis and see what it does, because it will really depend on how it’s pub/sub system works. However, no matter how they arrive, the end result will be correct.
There’s no mergebox anymore right? So clients might get updates to the same record twice?
You can already have publications that avoid the mergebox like the folks at rocket.chat do. Did you experiment with that and, if so, why did that not suffice?
Yes, there is a mergebox that stores client’s image on server, without it some things are impossible. However, there is a plan to have the same observer for the same publications (with same filters and options). Regarding data stored on the server. Come-on… RAM is cheap. I always prefer something that consumes more RAM rather than CPU :D, and to be able to consume 1GB of ram… you’ll need a LOT of Data.
Update: actually you just gave me a superbe idea, I can only store the current ids on the server’s image. that might just work.
The namespace is conceptually a simple query before you do a more complex one, right? This I might actually benefit from.
It’s not a query, it’s a namespace, meaning when you do inserts/updates/removes, you can specify in which namespace to publish, doing this, it will no longer polute the main collection namespace, therefor changes like that, could not be “heard” in a specific subscription, but we can make it so you can do that as well, to send it both to the main collection namespace and your dedicated one