Publications vs methods for current Blaze users

Hey guys, was wondering what people’s current preferences were for when to use pub/sub vs Meteor methods.

For single document pages (eg: a show page), pub sub seems like a real winner to avoid having to refetch on each change.

For “index” pages (eg: tables of documents), using pub/sub is nice as it feels like the default Meteor way, you can also put reactive variables for limit, skip, etc and let the subscription update.

However subscriptions can be hard, especially when you have multiple publications publishing similar data. Methods are a nice, sane way of fetching data in a predictable way but I find the more you start using methods for fetching data the more you question the benefits of Meteor over say backend + API.

I guess maybe a combination of pub/sub and methods gives excellent flexibility.

It depends on the usage of the page. If I have a page that doesn’t NEED to be updated all the time, like a news article, or information page, then I use methods. They are faster, easier and takes less resources.

I only use pub/sub for things that NEED to be live, like online status, colllaborative features etc. I would very much avoid using pub/sub if it is just “convenient” or nice to have, it has significant performance downsides for not much benefit if your don’t actually need it. In most cases, not updating things is “good enough”.

2 Likes

Thanks for the reply, does the main benefit of Meteor for you then become having pub/sub when you “need it” (statuses etc), or more to do with the front/back ends being so well-coupled? Or other reasons?

Well, I make heavy use of pub/sub because our app is very collaboration heavy, and the actions you take should be reflected immediately for you and the others using it. So In my case it is more a case of when I don’t need it.

So the main benefits for me becomes

  • Zero config magical build tool
  • pub/sub (I also love minimongo)
  • sharing code between sever and client
  • old browser support included
  • fibers on the server, making everything in sync and easy to reason about
  • good integration with the rest of the node ecosystem

All of this combined leads to incredible iteration speeds for our team.

Sure, you can get all these features if you cobble it together yourself, but I’ve done that, and it is a gigantic pain, a LOT more effort, a source of bugs, and needs continuous tweaking to keep working when I update something.

4 Likes

That’s a great answer, thanks

We’re building up a large web app with Meteor with many different areas of functionality and use pub/sub almost exclusively for fetching data. The main exceptions are where a report is delivered that has benefited from MongoDB aggregations (or equivalent preparation) on the server. But even some of these are then delivered with a custom publication simply because the convenience/standardisation of pub/sub is so appealing.

Many of our documents are quite large/complex/deep as is the document count so publications are almost always filtered by both number of documents returned and fields returned within. This in turn does lead to a frequent concern as to whether you have the expected set of data on the client. So you have to have some discipline on when and where you subscribe - by page and/or by component. Again, for a multi-layered app this can start to get quite tricky.

Our app does absolutely need to be real time, but it does not involve huge rates of changes so the potential performance issues are, for now, further down the line - but if you need to present data on a collection that has a high change rate take care, and if a snapshot will do then use a method in such cases.

But generally, the magic of the screen just changing to reflect the current data state never ceases to delight me (and users often express the wow factor on this too). It has never failed and seems to be extremely reliable.

2 Likes

Brilliant, thanks for sharing your experiences!