In 2011, when Meteor was not around, When u hit a site build on Rails, The client(i.e your browser) sends a request to your app, which lives on the server. The app finds out which data the client need, which could be of any size. Once the right data has been selected, the app then translates into human-readable HTML (or JSON in case of API).

Finally, the App takes the HTML code and sends it to the client’s browser. The app’s job is done here.

The Meteor Way

The feature that makes Meteor different from others is while Rails App only lives on Server, Meteor App lives both on Server and Client. Simply put, Meteor takes part of your database and copy it to client. This has two implications: Firstly, instead of sending HTML code to the client, a Meteor app will send raw data and let the client deal with it. Secondly, you’ll be able to access and even modify that data instataneously without having to wait for round-trip to the server(latency compensation).

Publishing

The App’s database can contain thousands of documents, some of which might contain sensitive and private data, So we cannot just mirror complete database to the client, for security and scalability reasons.

So we’ll need a way to tell the Meteor which subset of the data can be sent to the client which is accomplised through publications
[cc lang=”javascript”]
//on the server
Meteor.publish(‘posts’, function(author) {
return Posts.find({author: author});
});
[/cc]
The above method tells Meteor App to send Only those posts to the client which are written by author.

Subscribing

There can be thousands of authors who write posts on the site. We need a way for clients to specify which subset of that data is needed at any particular time, and that’s exactly where subscription comes in.

Any data you subscribe to will be mirrored on the client thanks to Minimongo, Meteor’s client-side implementation of MongoDB.

For example, let’s say we’re currently browsing Tom Cliff’s profile page, and only want to display his posts.