My english is not perfect, sorry !
I’ve been working with Meteor for 2 years now, and many times, I’ve been thinking about something.
When I want / need to reduce my server memory and cpu usage, I use cursor.observeChanges() rather than returning a list of cursors, in order to have a fine grained data handling.
In the added callback of that observer, when a notification doc is added for example, I then fetch the users linked to that notification and add them to the published documents.
But several questions then come to my mind :
- If many users (x) are subscribed to a same observer, when a new doc is added, the callback that handle fetching the users will be triggered x times anyway. Why couldn’t we have a hook earlier in the observer to hit our db only once and then spread the document to each publication related to this observer ?
- As meteor caches every doc published to the client for each observer living on the server, wouldn’t it be a good idea to be able to use that cache as a local sample of the database in order to check if I can find the data that interest me at a given moment ? If I do, I simply use them to avoid hitting my db when I already got the needed data localy, otherwise, I fetch them from the db.
Such possibility would be very nice to publish data faster and reduce the problem of joining data accross collections without having to make too many recomputation or denormalisation. It specially would be great for publications that need data that are already used by many other clients but that cannot be merged into a single observer, or for publications that are not based on observers at all.
May be there are packages or topics about that questions and that I haven’t found them yet, but it seems to be very interesting to me, specially if we could have the ability to use one single added callback for every pubs sharing a same observer.
What are your thoughts about it ?