Yup, seems like the hype took peoples common sense with it out the window. I'd assume and hope that just because there's a mongo api on the client, surely doesn't mean it's the raw socket that's exposed?
The way it works in Meteor is, there is a data cache on the client with a Mongo-compatible API. When you type commands in the browser console, you're not hitting the real Mongo database at all, you're hitting that client-side cache. That's why it can be synchronous.
When you do a write, it also does a RPC to the server to ask the server to do the same write. The server can accept the request, reject it, or do something totally different. Whatever ends up happening, the client cache is patched to reflect the results.
Geoff, a bit off topic here but do you have any comment on the GPL licensing/linking conversation people have been getting their nickers in a twist about every time meteor comes up on HN?
If the "autopublish" package is added to your project, which it is by default, then the entire dataset is sent to the client. That's good for learning and prototyping, but isn't any good for production use. The Leaderboard example uses autopublish.
Once you app works and you're ready to lock it down and scale it up -- and only then -- you remove the autopublish package. Now, it's up to you to define what's sent to the client. Use Meteor.publish() on the server to set up different datasets that clients are allowed to subscribe to, and use Meteor.subscribe() on the client to turn on/off a particular dataset. The Todos example demonstrates this -- it retrieves just the items for the todo list you're looking at, plus the list of lists. It's just a couple of lines of code, like 5 or 10, and not tricky ones either.
