Kadira - Performance Monitoring for Meteor (you should try this)

Understanding MergeBox

You may have heard this term somewhere before. If you haven’t, don’t worry. In this topic, we will be looking at what MergeBox is and how it works. It is one of the major building blocks of Meteor.

What is MergeBox?

MergeBox is a process that tries to identify the exact changes that need to be sent to the client, based on the data it receives from publications.

To understand this properly, let’s take a look at an example. Suppose we have two publications, as shown below:

Meteor.publish("app", function(appId) {
    var filter = {name: 1};
    return Apps.find({_id: appId}, {fields: filter});
});

Meteor.publish("appWithOwner", function(appId) {
    var filter = {name: 1, owner: 1};
    return Apps.find({_id: appId}, {fields: filter})
});

First, let’s try to subscribe to the first publication:

Meteor.subscribe('app', 'app-one');

As we expect, we get the following DDP message:

{
    "msg": "added",
    "collection": "apps",
    "id": "app-one",
    "fields": {"name": "kadira"}
}

Next let’s try to subscribe to the second subscription for the same appId:

Meteor.subscribe('appWithOwner', 'app-one');

Interestingly, we get a changed DDP message with only the owner field:

{
    "msg": "changed",
    "collection": "apps",
    "id": "app-one",
    "fields": {"owner": "arunoda"}
}

This is a result of a particular behavior of MergeBox. It has a copy of all the data available in each client. When a new subscription tries to send data to a client, MergeBox compares the subscription data with the particular client’s copy of the data. Then it will send only the differences to the client.

Limitations

Even though, MergeBox tries to reduce the number of data sent over the wire. It’s not perfect. MergeBox only work on the top level fields only. Let me show you that with an example.

Let’s imagine MergeBox has sent the following DDP message to the client.

{
    "msg": "added",
    "collection": "users",
    "id": "arunoda",
    "fields": {
        "name": "arunoda", 
        "address": {
            "city": "Colombo",
            "country": "Sri Lanka"
        }
    }
}

Now mergeBox has received a new version of the above document with a value change address.city to “Kandy”. Since MergeBox only works on top level fields, the DDP message it sends to the client looks like below:

{
    "msg": "changed",
    "collection": "users",
    "id": "arunoda",
    "fields": {
        "address": {
            "city": "Kandy",
            "country": "Sri Lanka"
        }
    }
}

So, if you are changing the structure or values of nested documents or arrays, you won’t get the full benefit of MergeBox.

Why MergeBox?

Now, you may be wondering: why MergeBox? Why is it in the server? Isn’t it going to consume more server resources?

Yes, you are correct. It will consume some additional CPU resources. But it’ll send the minimum amount of data down the wire, saving bandwidth and making the application faster. MergeBox comes in handy when Meteor applications are used on Mobile devices.


I hope you now have a clear understanding of MergeBox. But how it works internally is pretty awesome. You can learn more about MergeBox in my book Meteor Explained.

I’ve recently completed the “Publish Subscribe” Chapter and it has all the details for how publish subscribe works inside Meteor. There is a separate topic on MergeBox where I explain how it works clearly using some pretty illustrations.

Meteor Explained Book Cover

All main chapters are available right now.

This book comes with a 100% money-back guarantee and I’ll refund without asking any questions.

You can purchase Meteor Explained for $29.

Table of Contents

1. Basics (Available Now)

  • 1.1 Client–Server Architecture
  • 1.2 DDP
  • 1.3 Fibers
  • 1.4 Introduction to Meteor’s Reactivity

2. Client-Side Reactivity (Available Now)

  • 2.1 Local Collections
  • 2.2 How Deps works
  • 2.3 How Blaze Works
  • 2.4 Blaze and Reactivity

3. DDP Implementation (Available Now)

  • 3.1 Default DDP Connection
  • 3.2 Processing Incoming DDP (Client Side)
  • 3.3 Processing Incoming DDP (Server Side)

4. Methods (Available Now)

  • 4.1 Introduction to Latency Compensation
  • 4.2 How Latency Compensation Works
  • 4.3 WriteFence and It’s Usage

5. Publish/Subscribe (Available Now)

  • 5.1 How Publish/Subscribe Works
  • 5.2 Cursors and Observers
  • 5.3 Merge Box
  • 5.4 Deps and Subscriptions

6. MongoDB and Meteor (Available Now)

  • 6.1 Intro to the mongo Package
  • 6.2 Polling Observe Driver
  • 6.3 Oplog Observe Driver
  • 6.3 MongoDB Write Operations

Purchase Now