How can there be best practices when there's no production ready software? Best practices aren't derived from first principles -- they're a reification of all of the human experience that has gone into writing and MAINTAINING software systems.
The thing that concerns me about Meteor right now is that they seem to be fighting the use of the existing node ecosystem (e.g. not using npm, fibers) which makes it harder to use existing node libraries. Derby.js (<a href="http://derbyjs.com/" rel="nofollow">http://derbyjs.com/</a>) in contrast, build upon existing node components and plays nicely with npm.
I appreciate the brief diversion at the end (which I would summarize as 'make sure your users can't delete your entire database'), but it seems like there's nothing on which to base fundamentals/best practices for Meteor security yet...
Meteor is interesting but like others, I have some concerns. It's position within node.js community is a little strange to me. Also, this idea of "best practices" for something so new is just a little odd. Is it really a "baked" state where people can really build non-trivial apps or complex apps? I think you need a baked state plus time for best practices to actually develop.
"Note: Execute $ meteor remove autopublish on every project from the root project directory. It publishes all your data by default to the client and is poor practice."<p>This note does not belong in any article that also contains the heading "What is Meteor?". You should remove autopublish eventually, but it's a great piece of scaffolding.