MongoDB is a NoSQL database. Each record is a document and the set of documents is called a collection that is equivalent to a table in a SQL database. As you may know, MongoDB is an in-memory JSON-based database, which means it is extremely fast in favorable conditions. Usually, MongoDB can have operation logs, which is called oplog. The oplog has the database operations happening with time. This is used in the case of making the replica (slave) of the primary database. The operations that happen in the primary database are copied to the secondary databases asynchronously.

Though MongoDB is not a reactive database, Livequery, which is a part of MeteorJS, does some work internally to get the updates of the database periodically. Livequery can connect to the database and set triggers on certain conditions as required. In the case of MongoDB, triggers are not supported. So, the Livequery depends on oplog if enabled, or else it will poll the database at a particular interval. When oplog is enabled, which should be the case for production, MeteorJS observes the oplog and intelligently does the transaction. If oplog is not enabled, meteor polls the database, computes the diff, and then sends the changed data to a client. Livequery can guess when to poll the database as all the write operation to the database go via Livequery.

A very important part of MeteorJS is this good old design pattern. By default, the entire Mongo database is published to the client from the server. However, it is not good for production to auto-publish all the data to the client. Instead, the client can subscribe to the required data that is published by the server. The subscriber will automatically be updated whenever there is a change in the subscribed data:

/* Publishing from server. */
if (Meteor.isServer) {
  Meteor.publish("tasks", function () { //Registering "tasks" publication
    return Tasks.find();
  });
}
/* Subscribing from client */
Meteor.subscribe("tasks");

Being a developer, if you are implementing a table that can be sorted, filtered, and paginated, what will you do to make it faster? Won't you fetch the data and keep it in browser memory in the form of multi-dimensional array, apply all the operations on the cached array, and update the table as and when required? The same is the case for MeteorJS with little advancement in the cache implementation. Instead of using a plain object or array, MeteorJS creates a cache in the browser called MiniMongo, which is again a simplified client memory database. The highlight is that you can query it in the way you query the MongoDB that enables you to use the same query both in the client and the server.

Whenever there is change in MongoDB, the server sends the difference to the client and that data is stored in MiniMongo. At any instance, MeteorJS tries to keep both the MongoDB in sync.

Now, the data is with the client. Let's call this model. In a MV* framework, we have the views bound to models to auto-update the views as the model changes. In Backbone.js, you have to do it explicitly. However, in Angular.js, it is taken care of by the framework itself with the help of $ scope and digest cycles. How does MeteorJS handle data changes? With the help of Trackers. Trackers create observers for everything you need to track. By default, MeteorJS has enabled a tracker on certain data sources, such as database cursors and session variables. You can even have a custom variable to be tracked using the tracker.

Blaze is a templating engine that is reactive because of the tracker. Blaze plays the magical part of reactivity by binding the data to the templates. An important point to note is that Blaze is declarative, which means you just have to tell Blaze what to do when the data changes, and need not say how to do it. With the help of the tracker, Blaze keeps a track of model changes and reacts to the change. The default templates are spacebars. This is a variant of Handlebar's templating engine. You can use Jade as well. Blaze is again intelligent to compute the diff of what needs to be updated. It doesn't update all the template until it is necessary. Blaze handles the user interactions and thereby makes a call to the server, if absolutely needed.