Learning Meteor.js [Part 13]: A critique of meteor's pub/sub system.

One of my negative impressions of meteor is they way it handles publish and subscription of collections. Meteor merges the documents from all publications into the same client side collection and there is no way to know which document came from which publication.

Sounds complicated? Well, it is. There are many posts that try to explain what that means and what implications it has. In practice, this feature makes for extra burden at development time and extra difficulty of maintaining a meteor app.

You can see how this surfaces in the 'paging' feature of the app that I am writing:

a) Notice how the view has two similar variables (limit and loaded) with some synchronization between them. This is to handle the case where the client collection contains documents from other publications that may show up while paging if one is not careful. People run into it, people try to explain it, people are confused. I was one of them.

b) Notice how the query used in the server to fetch the documents is duplicated on the client. As far as I know, that just how things are.

In my opinion, this design decision makes it very easy to create brittle systems. For example:
- I am tasked with writing a feature for the web site, I create another publication and I can unknowingly break some arbitrary piece that also uses documents from the same collection without the proper guards.
- Worse, I may not immediately notice that I broke anything, because the problem only surfaces depending on how the documents from different publications intersect.
- The same thing goes for changing the query of the publication, you better remember to duplicate the query word for word on the client or who knows what will happen.

The pub/sub of collections is magical and I can see how it speeds up development, but I feel that it guides you to the pit of failure, where the intuitive way of developing will leave you with a fragile system.

So, what can be done?