We've almost looked at all of the communication that happens between a client and a server when making a Meteor method call. On the left here in the client, we have our Meteor Apply call, where we call the item' Insert function, passing up this document. And the idea here is to simulate writing or inserting this document into some database like Mongo. So the client sends up an RPC message or a DDP message with the Message Name method. And that tells the server that it wants to execute a method on the server.
And then here, over on the server, we have that method defined. And when it executes and there's a Return result-- in this case, My Doc ID-- the server sends back a result. And we can print that result out here in this callback.
Then, we looked at how the server can use a data structure called a Write Fence to hold off on sending this final Updated message until the document has actually been written to Mongo database.
But there's one more thing that happens here. And that is that the server guarantees that once this document has been inserted or updated or removed, another message gets sent-- or however many messages are required get sent-- to the client to update its data to reflect that of the server. So in this case, since we're inserting a new document, we'll see an Added message here. And the added message will have the document.
And so once the client has gotten this Added message-- or, again, it could be a Changed or Removed-- and there could be as many of these as required, depending upon how many writes happened inside of the server-side method-- once that's all done, the server will send this Updated message.
So to see this in action, I want to take a little detour and show you how Meteor collections actually use RPC under the hood. Now, this isn't a class on Mongo Live Data. But I think since you've been using collections in your applications, that will be the best way to give you more intuition about what's happening here.
So let's jump over to an application that actually uses a collection called Items, and then see how these messages get sent over the wire.
I created a simple Meteor application. And I removed the Auto Publish package. You'll see why that's important in a minute.
The first thing I want to show you is that when you create a Meteor collection, it add some methods, both on the client and on the server. And so it actually uses Meteor methods, or RPC under the hood, when you call Insert, Update, or Remove.
Let's take a look at those methods. If I say Meteor Connection and take a look at that object, we can go search for the methods that have been created. So let me make this a little larger. And you can see that there's an object in here called Method Handlers. And inside of there, we have a methods that have been created for each of the Mutation functions for the Items collection. And so here's a Meteor method for Insert, and then another one for Remove, and another one for Update.
And if we looked on the server, we would see these methods are defined there as well. So here, we're looking at the method stubs. And then, if we were to come over here on the server, we would see the same methods defined here, like this. Items, Insert, and then one for Update and one for Remove.
OK. Let's try this out. On the client, I'm going to insert a document into that Meteor collection. So to do that, just like in your apps, I'll type Items Insert. And then for the doc, I'll just give it a title. And we'll just call it 1.
And what I want to do is to look at the DDP messages that have been sent over the wire. So I'll update the WebSocket tab here and take a look at the frames. We can see in the DDP area that just by calling the Insert method, somehow under the hood, Meteor called this Meteor method. And the name of the method was forward slash Items forward slash Insert. And as the parameters, it passes up the document that we're inserting.
Then, we get back an Updated message from the server. And then also a Result message from the server. And if we look at the result from the server, it's the ID of the new document.
But strangely, we don't see an Added message here. And if we added the document on the server-- in other words, if this document was inserted, we would expect to see an Added message for the new document. The reason that we didn't get an Added message is because the client isn't subscribing to any subscriptions that have this document in it.
So we have to go back to our subscriptions chapter. And if you remember from that, we need to subscribe to data in order to have it visible on the client. And so in this case, even though we made an insert, this added message isn't sent back.
So to fix that, let's just create a subscription. On the server, I'll use Meteor Publish and we'll publish a subscription called Items. And I'll just return Items Find. And remember that from the subscription chapter, that this is just calling Observe Changes and publishing out Added, Removed, and Changed messages for the cursor.
Now, over here, what we need to do is to subscribe to the Items publication. And now the client should have a view into that data set.
This time around, let's make another insert. And I'll give this a title of 1. And again, we'll refresh the WebSockets tab and take a look.
All right, this time around, when we made the Insert call, an RPC message is sent up for a method call. And again, we call the Items Insert method with the document as parameters. This time around, we get the initial result, which is still the document ID. And this is from the Meteor method on the server. But then, before we get this Updated message, we get an Added message, saying that the server has added this message. And to get our client view of the data up to date, we need to add it as well. And so it's for the collection Items with the document ID and the particular fields.
Important thing to note is that this Added message gets sent and received by the client before it gets the Updated message. And so by the time we get this Updated message, we know the entire method is complete, and we have all of the data that we need to update our local cache from the server. In this case, we get the Added message from the server saying that we need to insert the document.
Let's try the same thing. But this time, we'll call the Changed method of Items. So I'll get the ID of the first item in the list, here. And I'll call Items Update. And we'll update the first item. And I'll just set the title to a new title with a version of 2.
And once again, let's update the WebSocket view and take a look. This time we make the method call, except instead of calling the Items Insert method, we call Items Update. And again, with the parameters. And then, we get back a result from the server. And the result has 1, which is the number of documents that have been updated. And then before we get this Updated message, we get a Changed message. And the server's telling us that this is the document that has been changed, and these are the new fields.
Just to complete the process, let's call Remove. And what we'll remove is this one document in our collection. And once again, this time we make a method call, but it's to the Items Remove method, with the parameter of the ID of the document that we want to remove. And we get back a result, and then also a Removed message saying that the server has removed this document with this ID. And then, once we have the result and this Changed message, we get the Updated message from the method saying that the method with the ID of 3 is completed.
At this point, you've seen all the messages than can get sent as part of an RPC exchange or Meteor method exchange. In this video, we looked at Meteor collections. And the reason we did that it was to simplify showing off these concepts.
Specifically, we looked at how when you create a Meteor collection on the client or the server, Meteor methods are created for us automatically. When we call Insert, Update, or Changed on the Items collection, Meteor automatically makes a Meteor method call.
Then, we looked at how we could get a result from the server. And before we get this final Updated message indicating that the Meteor method is complete, the server will stand any number of Added, Removed, or Changed messages to get the client's view of the data up to date with that of the server. The way that these messages get sent is when the client subscribes to a data set, like we have here.
In the next couple of videos, we'll break down some of the mechanics of how this works. But I wanted to show it to you using just regular Meteor collections, so that you can make the association with your own applications before getting bogged down in the details.