The event loop and the merge box

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

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? Meteor.methods(), Meteor.publish(), and 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 external_API_query_unblocked instead.

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

Tip

It is very important to keep the event loop in mind, especially when we're connecting our web application to external services that are going to cause massive delays to our server.

The merge box

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.