Pro Meteor is a guide that has been created as a reference for building a production-quality Meteor setup. The guide assumes that its reader has a basic understanding of Meteor, but for readers that need a better introduction, Discover Meteor comes highly recommended.
This article is an introduction to Meteor’s internals, and serves as the foundation for future articles in the Pro Meteor guide.
A Meteor application is seen by browsers, proxy servers, routers and other network components as a typical web application. Yet Meteor is comprised of two main components: a part that runs inside the browser and another part that runs inside the server. These two parts are configured to communicate with each other in a way that’s similar to modern web applications (e.g. Gmail and Trello).
Meteor allows developers to build applications without worrying about the complexities of client-server connectivity.
Underneath its surface, Meteor handles 3 types of requests. They are:
Static files are images and other resources inside the
/public folder. Meteor serves these files automatically when the app starts.
DDP is the protocol Meteor uses to communicate between client and server. All client-side subscription data, method calls and MongoDB operations are communicated as DDP messages. This is a very lightweight protocol. These messages can be inspected with a handy tool called ddp-analyzer.
While there is no official documentation, Meteor can handle HTTP Requests similar to other traditional applications. For example, file uploads to a Meteor app are sent as HTTP Requests. See this StackOverflow question for details on how to manually handle HTTP requests.
Although Meteor runs on a single port, internally it works as two separate servers:
The HTTP server is used to serve static files and HTTP requests. Meteor uses the
connect Node.js module for this purpose.
The DDP server handles all publications, MongoDB operations and Meteor methods. Meteor uses SockJS as the transport protocol. In actuality, the DDP server is a SockJS server customized for Meteor.
Future guides will detail how to scale these two servers separately.
Meteor is built top of the MongoDB and Meteor is totally depending on MongoDB at this moment. But this can be changed in the future. But MongoDB is not a real-time database; but Meteor is realtime. Meteor makes MongoDB realtime using two techniques as shown below.
Polling is very expensive operation and that’s why Meteor includes another option (using oplog). But it needs some additional setup and is not possible with shared MongoDB hosting services. I will talk more on this topic in a future section.