Pub/sub is cool for reactive data, but if you just want to get data from the database, it’s really overkill and so it must be avoided in production. This was presented to me as a footnote and something I was oblivious of for a while, every seminar I watched, every starter app I have seen - takes full use of pub/sub and nothing else.
I know it’s common knowledge here to those more experienced, but sadly it isn’t told to the newbs and start-ups in the space.
None of the starter projects I have seen use a Method for the home page. I’ve even seen people asking here should they put their landing page in Wordpress. This is backwards beyond belief. Meteor is very powerful, so much so it is the swiss army knife of web development you can do anything you desire with meteor as a framework, and fast. You will leave other devs in the dust with the speed of how you can get an app together in days with Meteor, it does live up to it’s name in development, but ironically in production it’s not true, more like a crash landing.
Since I found Meteor many years ago as Meteorite, I have been sure that it was engineered by a group of geniuses. And it has just got better over the years really.
With all that said - Pub sub is awesome but use Methods for everything you can, you will get much better performance, also leverage memcache and Mongo views so that you do not have to deal with reactive data unless you want it. I have reduced overhead by two thirds doing this. Any other tips or tricks that the Meteor 1337s here can shed light on I would love to hear. Offline storage (GroundDB) and WebApp are also two extremely powerful libraries that need more widespread knowledge. WebApp alone is essentially Express inside Meteor. Understated and very feature rich. Haven’t seen any example Apps using it at all. But maybe I didn’t look hard enough. Thanks for listening, whatever you can add I would love to hear.
I think should be made more obvious, that it highly depends on the use-case, whether pub/sub is a useful and feasible technique for data handling.
Examples where pub/sub will not be that big of an issue:
multiple users relying on live-updates from a single document (example query: { _id })
one or multiple users relying on live-updates from the same group of documents (example query: { _id: { $in: [...] } })
Still okay but not so good examples:
one or multiple users relying on live-updates from arbitrary documents from the same collection over a limited amount of time, which requires, that after a short performance spike the sub is stopped
Avoid pub/sub when
live-updates are not urgent
relying on multiple data per user
sub from multiple collections
Also it is hard for many beginners to realize, that they have to refactor their data models to be pub/sub-optimized and not the other way around.
It was one of the hardest topic at the beginning. I can see that the feature is very good to sell Meteor.js for newcomers. Pub/sub has a trade off and must be used with cautions.
That’s right. When I build the notification feature, if I used pub/sub to load list of notifications then it would put a heavy load on my server if we have hundreds of concurent users.
But instead I create other collection which stores notifications status, one record per user. Then user just subscribes to this ONE document only. When user has new notification, I update the “lastItemDate” in this document, then on the front-end, user will load new notification items by using method call.
Great post. I inherited an app that was not prod ready (a lot due to unnecessary pub/sub …and publishComposite with thousands of docs across like 10 colls).
I made a post Updating DOM with saved DB values without Reactivity which explains where the app could actually take advantage or reactivity. Basically…input in table can get updated to another value in DB onBlur. My question there was kinda philosophical. Basically, how UI was updated from DB values swiftly wo reactive tech.