Comparing three different solutions for observeChanges "CRON" jobs

Hi,

Typical use case in a denormalized scheme: Bob changes his username, so all documents that have his username must be manually updated.

Solution 1: Observe the entire user’s collection by query == {}. IIUC, this observer will run N times if there are N people connected. That sounds like awful redundancy.

//in app's server side code
Meteor.users.find({},{fields:{username:1}}).observeChanges({
    changed: function(id,fields){
        //update all docs to reflect changes;
    }
});

Solution 2: Kill the redundancy by observing a much smaller collection set per connection, namely, the current user’s object ONLY.

//in app's server side code
var currentUserId = Meteor.userId();
Meteor.users.find(currentUserId,{fields:{username:1}}).observeChanges({
    changed: function(id,fields){
        //update all docs to reflect changes;
    }
});

Solution 3: Forget an in-app solution, and run a secondary meteor process whose sole purpose is to observe the database for these operations.

//in a completley different meteor app, server side code.
Meteor.users.find({},{fields:{username:1}}).observeChanges({
    changed: function(id,fields){
        //update all docs to reflect changes.
    }
});

Solution 1: Runs N observers which all observe all documents in the Meteor.users collection.
Solution 2: Runs N observers which only observe the user from which the observer was instantiated.
Solution 3: Runs a single observer, which observes all documents in the Meteor.users collection.

Is my reasoning correct that Solution 1 is unecessesary and redundant because solution 2 achieves the exact same thing? What are your thoughts on solution 3?

1 Like

I think I’ve misunderstood how the server initializes each client - rooted in a fundamental misunderstanding of node-fibers.

This means that the situation is different. OK. The question is still left open -

Solutions 1 and 3 above are effectively the same, because the observe only runs once (after a small test I ran), but solution 3 is probably overkill. There is still the possibility of solution 2, which could work if I ran an observer in the Accounts.onLogin callback server-side. Instead of globally observing Users.find({}), I could observe many Users.find({username:idOfWhoJustLoggedIn})

My theory is that there is no point in seeing when a thing will change unless the only person that can make that change is online. Don’t observe User.username for Bob unless Bob is logged in and could potentially change it. Else, I’m observing a whole lot of unnecessary documents.

But the biggest issue is: Is it better to have many little observers for each logged in user, only watching a single document each, or one big observer that watches the entire collection? That will determine the solutions chosen. See my other question: Single observer for a document that can change many ways vs. Many observers for the document that all focus on a specific change

Thoughts? All appreciated. thanks.