TLDR: Read the f*** manual.

I didn’t read the meteor docs carefully enough: Not all published rows are sent to the client, only the needed ones. See here for further explanations.
This answers my questions from this post.

I spent some hours working with MeteorJs and AngularJs. One of the big advantages of MeteorJs should be the publish/subscribe-schema. But I have my problems with it.

I had this case and thought long about how to solve it:

Social app where an user can write posts on a public stream. Other (or the same) user can comment and like the post and like comments. The stream view is limited to 10 posts and loads more when the user scrolls down.

What is going to be published?

(only concerning posts, comments and likes)

Public stream

  • last 10 posts
  • all comments from this last 10 posts
  • all likes from this last 10 posts and from the comments

So I already implement relational logic on the server (to publish the right things) and again on the view. I don’t want to publish all data since after some time it will be too much (or am I missing something?).

Look at a post

  • Same as above but for one post only

Same problem as above but now we have an post-id as argument instead of limit/skip.

You can think of more views… and it’ll get more complicated.

Now why don’t use a classical api where you “get post with id x” or “get last x posts”. One api-route usually corresponds to a view and you get all the data from it (or you can implement it differently). Still the MeteorJs solution with publish/subscribe is more complicated and more messy in my opinion. I must have missed the point for the publish/sub model unless one wants to build small applications…