In this video I'd like to introduce Meteor's publish and subscribe system. It's one of the key ways that we're able to get data from the server to the client, and then to keep that data up to date as it changes over time. Let's take a look at an application example. On the top left I have my client code, and on the top right the server code, so that we can clearly see the difference.
And the way this works is the client will subscribe to a data set, or to a named publish function. In this case I'm asking for the publish function called last few items. The server creates a publish function by calling Meteor publish, giving it a name, and then a function to run when a client connects and wants to subscribe. A typical example of a published function is one that returns a cursor.
In this case we're returning a cursor from the items collection, and we're finding the last three created items. Down below we've used Meteor's collection in the browser, called items, and we called find.fetch, and you can see the three items that we got from the server here. Let's take a closer look at what's happening. Let me draw a diagram.
On the server, let's pretend we have a big collection called items. So I'll draw this with a bunch of lines, and these will be documents in the collection. And this is our items collection on the server. On the client, what we want to do is to get a view into that data. So I'm going to draw a smaller collection to say-- let's just say we want the top three documents.
What pub/sub gives us is the ability to get a view into the server side data. In other words, it's what the client can see. So the way that we're able to do this is the client can subscribe or make a subscription request, so it sends up a DDP message to the server that looks something like this. Then the server is going to send back, or is going to run this publish function, so let me change the color here.
And it's going to send back the initial data set. So in this case we're going to have three documents, and what it's going to do is to send three messages back to the server, or back to the client-- one for each document. These messages are called added messages. So we'll send one added message for each document in the result set.
Once those initial documents have been sent, the client need some way to know that the server is done sending the initial messages. And the way that happens is the server can send an additional message called the ready message. And when the client receives this, it knows that the initial result set, or the first three documents here have been sent down.
One of the cool things about publish functions is that once we have our initial data set, at some later time, let's just say two or three minutes later, the server can send additional messages to change the data set. For example, it might send an additional message, which is called a changed message, to change one of the documents. And it might also send another one called a remove to remove a document.
And it can even add more documents by calling the added, or sending an added message. And so this allows the client to get a stream of messages over time that can change our view of the data. And when the client is done and it doesn't want to receive these messages anymore, it can send an additional message up to the server to unsubscribe from the published function, and then it won't receive anymore messages for this publish function.
And any data that was associated with the publish function will be cleaned up automatically. In this video we looked at how the pub/sub system in Meteor lets a client get a view into data.
In other words, it decides what data the client can see. We look at a little bit about how the DDP protocol supports this feature with messages like sub, added, ready, changed, removed, and unsub. In the next couple of videos we'll look at the mechanics of the publish and subscribe system in some code.