Your claim that the client has a full copy of the server's data is incorrect. By default that is the case, but removing such functionality takes only a few lines of javascript and removing the "autopublish" package (one command).
Seriously, Meteor has grown up a lot recently. This stuff moves quick. I encourage you to take a look at it again, because I imagine many of your initial problems with the platform have been settled - there are still people out there who feel any user can clear out the whole DB from the client .
No stopping autopublish doesn't solve anything in this case. In my leaderboard example, the clients view of the highscore is dependent on all data in the collection which has to be published and the client has to subscribe to it.
Even if you only want to show the best 10 scores of your 500k population, Meteor doesn't allow you to subscribe to the Mongo equivalent of "select player, score from results order by score desc limit 10" (last I checked anyway) And even if it did, well what if you want to see result 11-20 or the 10 best scores among your friends?
You or someone else is very welcome to prove me wrong here and I'll admit I'm an idiot. All that is needed is 1 grid, 500k items, allow me to sort up and down on the headers and let me paginate through it as I please and support 5 simultaneous users. Trivial to write using Rails or Django. I claim impossible to write in Meteor.
It's quite easy, and you still get reactivity. You publish the collection as before, but you write a server-side filter (a well-documented core feature) that only sends a small piece of that to the client. Even though the client only sends a small piece, the changes to those items are still reflected back to the server and other clients live.
It's supported this from the day it was released - I remember hooking up something quite similar at the time. It was never purely autopublish.
In addition to that to make robust pagination you need aggregation. Printing the message "you are looking at page X of Y pages" requires you to know the count of the collection or else you can't say how many pages there are. I.e You need to reactively monitor MongoDB's equivalent of "select count(*) from blaha". Doing that (without cheating and caching the count) is very expensive in Meteor.
One count(*) query per request is not expensive at all. Suppose you cache the count and someone else adds rows to the collection. Your cached count is not getting updated and the whole reactivity concept breaks down since your app now thinks the row count is different from what it really is.
Yep, if only the "forces of thruth" actually knew what they were talking about it would have worked great. :) Btw, I've asked for help in other places (which I won't link to as I like to keep my internet identities somewhat separated) but no one has an efficient way to deal with large collections.
> Meteor doesn't allow you to subscribe to the Mongo equivalent of "select player, score from results order by score desc limit 10" (last I checked anyway) And even if it did, well what if you want to see result 11-20 or the 10 best scores among your friends?
That's actually all possible. Just write a good publisher which takes the number of results as an argument. All the sorting can happen on the backend and then you push down the x results.
Sure, not as effortless as autopublish, but also no harder than in traditional apps.
Seriously, Meteor has grown up a lot recently. This stuff moves quick. I encourage you to take a look at it again, because I imagine many of your initial problems with the platform have been settled - there are still people out there who feel any user can clear out the whole DB from the client .