I imagine it's just using localStorage under the hood, and it's selling point is that it exposes the mongo api you'd use for interacting with the db, or is there something else that I missed?
More that it fully simulates the mongo api. When you perform an insert/update on the client, the following will happen:
1. The command will be sent to the server.
2. The command will be performed on the local database, but backing up the original local DB state so that it can be reverted if needed.
3. Immediately, any helper functions used by templates which rely on data from the DB will react to the change in the local DB and inform their template instances to update just the relevant part of the DOM.
4. The server will eventually get the request, and authorize it based on allow/deny rules.
5. If the command was allowed, the server will update the actual DB, and use MongoDB's oplog to notify all other server instances that the data has changed.
6. Server instances will send the changed data down to all subscribed clients, which update the state of their local DBs, causing the templates to re-render the relevant parts of the DOM.
7. If the request was denied on the server, the server informs the requesting client, and the client patches up its local DB to the actual DB's state, also reverting the DOM state.
So you have built-in latency compensation and full-stack reactivity by default. The client anticipates the server's response, making the application feel extremely responsive. But if something goes wrong, the client patches itself up with the actual result. Of course you can avoid latency compensation altogether where you don't want it - just avoid using the isomorphic API on the client and use RPCs instead. The servers will still inform the other server instances and push the changed data down to all the subscribed clients, but the requesting client has to wait like everyone else before the DOM is updated.
Another point to add is Meteor's EJSON, which is a simple spec for defining how any complex, constructed or factory-made JavaScript objects should be serialized to JSON, and then deserialized back into a full JS object with behavior. Objects inserted/retrieved to/from the MongoDB or Session variables are automatically serialized/deserialized if you have made them EJSON compatible (quite easy to do, and built-in for Date and binary objects). By sharing EJSON definitions on the client and server, you have a flexible basis on which you can build an isomorphic model layer to your liking. The constructed model objects you're working with can easily be made identical (truly or superficially, depending on your needs) on both the client and server code.
