Meteor, communication between the client and the server

Question

This a snippet from the todo list tutorial. Variable checked is represented both on the client and the server side? How the client and the server communicate to make checked consistent?

Template.task.events({
  'click .toggle-checked'() {
    // Set the checked property to the opposite of its current value
    Tasks.update(this._id, {
      $set: { checked: ! this.checked },
    });                                                                                                              
  },
  'click .delete'() {
    Tasks.remove(this._id);
  },
});

Answer 1

checked is an attrubite defined on a Tasks object, as defined in this app.

In Meteor, the definitive record of this object is stored on the server (in MongoDB ), however there is a client side cache that is also being manipulated here, known as MiniMongo . The Meteor framework does a lot of work in the background (via the DDP protocol) to keep the server and client side objects in sync.

In this case the following is happening when a user clicks on a checkbox (firing the 'click .toggle-checked' event code) in the Tasks.update method:

1. First update client side MiniMongo Cache - this is known as Optimistic UI , and enables the client UI to respond fast (without waiting for the server)
2. Send a message to the server ( Meteor Method ) that the client wants to update the Tasks object, by setting the clicked variable to a new value.
3. Message requesting update received by server, which checks this is a valid operation, and either processes it (updating MongoDB version of the Tasks object, or refuses to process the update as appropriate.
4. Server will send out a DDP update of the resulting status of the Tasks object to all clients that have subscribed to a publication that includes it.
5. Clients that have previously subscribed will receive this DDP update, and will replace their MiniMongo version with the Server's version of the Tasks object, ensuring that all Clients are in sync with the Server.

Now in the ideal case, when the server accepts the clients changes, the new version of Tasks received (in step 5) by the initiating client will match the object it optimistically updated (in step 1).

However by implementing all these steps the Meteor framework also synchronizes other clients, and handles the case when the server rejects the update, or possibly modifies additional fields, as appropriate for the application.

Luckily though, this is all handled by the Meteor framework, and all you need to do is call Tasks.update for all this magic to happen!

Answer 2

Meteor likes the blur the lines between client and server. There are things you can do to abstract code -- for instance, javascript files (among all files) inside the /server directory to restrict access to it. This means that client users can't see this code.

/client obviously is the opposite. You can check a file with isClient and isServer .

Now, what does this mean to your code?

Depending on where your code is, there are different access levels. However, inside the script, there basically is no difference. checked is known on server/client inside that script because that's how Meteor runs, the blurred line between client and server makes this possible.

Meteor employs something called "database everywhere" which means it doesn't matter where the code is called, because it will run.