Latency compensation and allow/deny rules

help
1

Does latency compensation still work if the client is denied inserting a document?

For example consider the following code. Do I still profit from latency compensation?

// in lib/methods.js
Meteor.methods({
    updateDoc: function(doc) {
        MyDocs.insert(doc);
    }
});

// in server/rules.js
MyDocs.deny({
     insert: function(userId, doc) {
        return true;
    }
});

//in client/functions.js
Meteor.call("updateDoc", doc);
1 Like
2

When you’re not sure about these stuff, it’s best to try them out. You can also use meteorpad.com for simple demos. (I made one for you here).

Meteor uses some internal methods when user does something with a collection on the client side. These are named like /my-docs/insert, /my-docs/update, /my-docs/remove, … This is where Meteor’s allow/deny rules are checked.

I’ll try to explain what happens when the Meteor.call(...) line is executed on the client.

  1. The updateDoc method handler is run on the client. This is called a simulation.
  2. When MyDocs.insert(doc) is called on the client, Meteor usually calls /my-docs/insert but this time as we’re already inside a simulation, it will just return. So the document is not inserted at this time. So we don’t get latency compensation.
  3. Then the updateDoc method handler is run on the server which will successfully insert the document and send an updated message to the client.
  4. The document will be added to client side mini mongo collection and gets rendered on the client.

You can use Kadira Debug to learn what’s happening inside Meteor. I’ve attached 2 screenshots. First one is taken after running MyDocs.insert on client. And second one is taken after running it on server with a kinda not-working latency compensation (as in your code).

4008×2448 457 KB
4064×2504 486 KB

1 Like
3

Thanks a lot for the detailed answer. Very helpful!