How are you sure that data you are getting from the cache is not stale?

[mitar]

I do not see it anywhere in the code. You are assuming there is an observe happening?

Isn't merge box populated only when you do observe and not just a regular MongoDB fetch?

I think this works for you because you have a default publish endpoint to publish current user to the client, which has an observe setup.

[msavin]

The cache is constantly being updated by the oplog.

Here’s how Meteor’s real-time data works:

Oplog Tailing > Merge Box > Pub/Sub

All the data that is delivered via Pub/Sub is first processed in the MergeBox.

Thus, any change to your user document is available on the server even before it makes it to the client.

[mitar]

Yes, but oplog tailing is enabled for a document only if there is a query matching it. So what happens if there is no active query matching current user?

[msavin]

How can a logged-in user not have a matching document?

[mitar]

What I am saying is that this is true because client subscribes to the server using null publish for current user. We should make sure that this publish is activated and populates mergebox always before anyone else can call Meteor.user(). I am not sure if this is true, but maybe it is and maybe null publish do have precedence over others.

Personally, I would prefer the following approach: I would in onLogin callback add an observeChanges on the current user which would populate a per-node process Map. Then Meteor.user() would query that Map. In this way the effect is the same, but we have an explicit call which makes an oplog call, and we also can exactly control which fields we want to observe.

I do not think that it is so costly to copy from merge box using observeChanges to Map, but it feels less hacky.