Before diving into Meteor, it is critical to understand what the event loop and the merge box are and how they can adversely affect your code. Both are relatively complex in the way that they were programmed, so we will focus on understanding the general concept.
The event loop is like a queue; it runs a series of functions one by one. Because functions are processed sequentially, each function effectively blocks others from being processed until the function is done.
In other words, the event loop functions much like a single-line conveyor belt where things are being inspected. For every inspection made, the line is stopped and nothing moves.
Meteor uses Fibers – a NodeJS library – to get around this issue. Many of the functions that you will run will be on a separate fiber. What does this mean? This means that the functions will run on a separate conveyor belt for processing. Still, not all functions are built this way, you need to make sure your server-side functions do not block the server.
So which functions could potentially cause the server to get blocked?
any function that does not run inside a fiber on the server. Let's see how we can unblock each one and when we should do this.
Functions defined under the
Meteor.methods() that you know are going to take a long time to process, should always run on a Fiber or defer time consuming code to a Fiber. We can quickly solve this by calling the
@unblock() function from within the method. Let's look at an example:
# METEOR METHODS Meteor.methods #BLOCKING time_consuming: -> Meteor.setTimeout -> console.log "done" ,60000 #NON-BLOCKING time_consuming_unblock: -> @unblock() Meteor.setTimeout -> console.log "done" ,60000
In this example, when you run
Meteor.call("time_consuming"), the server will be blocked. When the server is blocked, other visitors won't be able to reach your site! Instead if you run
Meteor.call("time_consuming_unblock"), the server will continue to function properly but consume more resources to do so.
Meteor.publish() can be easily unblocked after installing the
meteorhacks:unblock package as well. This one will be particularly useful when we start to make very complex publishers that might consume a lot of resources. Let's look at an example:
# METEOR PUBLISH #BLOCKING Meteor.publish "external_API_query", -> HTTP.get "http://connect.square.com/payments" #NON-BLOCKING Meteor.publish "external_API_query_unblocked", -> @unblock() HTTP.get "http://connect.square.com/payments"
In this example, we are waiting for an HTTP call to respond. This will certainly block the server if we subscribe to
external_API_query, so we use
All other functions that run on the server and you know are going to block the server, should run on a fiber. Meteor has a special function to help us make this easy. It is called
Meteor.wrapAsync(). Let's see how this works:
# METEOR UNBLOCKED FUNCTION unblock_me = Meteor.wrapAsync -> Meteor.setTimeout -> console.log "done" ,60000
The merge box is the algorithm that identifies all the changes that are happening to the database. It basically handles publishers, subscribers, and reactivity. The merge box also handles the initial load of data using DDP messages.
It is important to understand that we can communicate directly with the merge box via all the commands that are available to us under the
Meteor.publish() function. The more optimal we can make our
Meteor.publish functions, the faster the site will load.