Other users have answered these pretty well by now, I'd just like to add to the discussion of this question: >Likewise, I'm confused about how to get around the limitations of mongodb. Say you run a store with a finite inventory, how do you handle concurrent purchases? How about a website to enroll into classes? How about a webforum which can have exactly 5 administrators? A quick&easy for me has been to just set up a separate REST API to handle critical data like payments and just have a two-server app. Doesn't really add to development time vs a unified server. Meteor doesn't preclude SQL use, it just doesn't support reactive SQL off the shelf like it does Mongo.

Cant tell if this is sarcasm or not :P

Removing autopublish and writing methods is not the same thing as rewriting the whole thing. But if you want to skip autopublish, you can do so from the beginning. As mentioned elsewhere the ability to perform a database action initially on the client allows for latency compensation, which is a significant user benefit beyond fast prototyping.

The table of contents is right there on the homepage. And you can read the first four chapters for free here: http://book.discovermeteor.com