That being said, I do believe the hardest part of all these attempts to abstract backends is authentication and security models. It seems to me that most of these services launch before figuring out that critical part of the puzzle.
Figuring this stuff out is hard. Usually for questions that come up in this shift, we have a good model we can look at, which is the client/server desktop applications of the late 80s and early 90s. But in the case of authentication and security, they tell us not so much, because in those days most software lived inside private corporate silos. These days, our software not just technologically distributed, it's politically distributed.
In the case of Meteor, it's designed from the ground up for security. In fact, it's a second generation security model, designed after reflecting on lessons learned from Asana's Luna platform (I worked on Luna at Asana for a while in 2010.) It just isn't exposed in a user-friendly way in the Tuesday release.
But people dug into the code, found it, and are using it anyway, whether we like it or not. Briefly, 'meteor remove autopublish', use Meteor.publish to define what data clients can access, use Meteor.subscribe to control what data a particular client is getting, use Meteor.methods to define what writes clients can do, and see the following Stack Overflow question to disable the 'newbie mode' insert()/update()/remove() that let you do arbitrary writes to the database.
http://stackoverflow.com/questions/10115042/how-do-you-secur...