Meteor 延時補(bǔ)償

延時補(bǔ)償

在上一章，我們介紹了 Meteor 的一個新概念：內(nèi)置方法。

Meteor 的內(nèi)置方法是一種在服務(wù)器上執(zhí)行一系列命令的結(jié)構(gòu)化方法。在示例中，我們使用內(nèi)置方法是為了確保新帖子是通過作者的姓名和 ID ，以及當(dāng)前服務(wù)器時間去標(biāo)記。

然而，如果 Meteor 用最基本的方式去執(zhí)行內(nèi)置方法，我們會注意到一些問題。想一想下面事件的序列（注：為演示方便，時間戳值是隨機(jī)的生成的）：

• +0ms: 用戶單擊提交按鈕，瀏覽器觸發(fā)內(nèi)置方法的調(diào)用。
• +200ms: 服務(wù)器更改 Mongo 數(shù)據(jù)庫。
• +500ms: 客戶端接收到這些變化，并更新頁面反映更改結(jié)果。

如果這是 Meteor 的操作方式，它會有一個很短的時間差去看到這樣的執(zhí)行操作的結(jié)果（延時的多少會取決于你的服務(wù)器性能）。但我們不可能讓這些情況出現(xiàn)在 Web 應(yīng)用程序中！

延遲補(bǔ)償

為了避免這個問題，Meteor 引入了一個叫做延遲補(bǔ)償（Latency Compensation）的概念。如果我們把 post 方法的定義放在 collections/ 目錄下。這意味著它在服務(wù)端和客戶端上都存在，而且是同時運(yùn)行！

當(dāng)你使用內(nèi)置方法的時候，客戶端會發(fā)送請求到服務(wù)器去調(diào)用，同時還模仿服務(wù)器內(nèi)置方法去操作本地數(shù)據(jù)庫集合。所以現(xiàn)在我們的工作流程是：

• +0ms: 用戶單擊提交按鈕，瀏覽器觸發(fā)內(nèi)置方法的調(diào)用。
• +0ms: 客戶端模仿內(nèi)置方法操作本地的數(shù)據(jù)集合和以及通過更改頁面來反映這一變化。
• +200ms: 服務(wù)器更改 Mongo 數(shù)據(jù)庫。
• +500ms: 客戶端接收這些更改并取消剛剛的模仿操作，根據(jù)服務(wù)器的更改覆蓋它們（通常是相同的）。頁面的變化反映了這一過程。

這樣用戶就會立刻看到變化。服務(wù)器的響應(yīng)返回一段時間后，根據(jù)服務(wù)器數(shù)據(jù)庫發(fā)送過來的更改請求，本地數(shù)據(jù)庫可能會或可能不會有明顯的改變。因此，我們應(yīng)該學(xué)會確保本地數(shù)據(jù)盡可能地與服務(wù)器數(shù)據(jù)庫保持一致。

觀察延遲補(bǔ)償

我們可以對 post 內(nèi)置方法的調(diào)用稍作改動。為此，我們將會通過 npm 包 futures ，使用一些高級的編程方式去把延遲對象放到我們的內(nèi)置方法調(diào)用里面。

我們將使用 isServer 去問 Meteor 現(xiàn)在所調(diào)用的內(nèi)置方法是在客戶端被調(diào)用（作為一個存根 Stub）或是在服務(wù)器端。這個存根 stub 是模仿內(nèi)置方法在客戶端運(yùn)行的模擬方法，而“真正的”內(nèi)置方法是在服務(wù)器上運(yùn)行的。

所以我們會詢問 Meteor 這部分代碼是否在服務(wù)器端執(zhí)行。如果是，我們會在帖子的標(biāo)題后面添加 (server) 字符串。如果不是，我們將添加 (client) 字符串：

Posts = new Mongo.Collection('posts');

Meteor.methods({
  postInsert: function(postAttributes) {
    check(this.userId, String);
    check(postAttributes, {
      title: String,
      url: String
    });

    if (Meteor.isServer) {
      postAttributes.title += "(server)";
      // wait for 5 seconds
      Meteor._sleepForMs(5000);
    } else {
      postAttributes.title += "(client)";
    }

    var postWithSameLink = Posts.findOne({url: postAttributes.url});
    if (postWithSameLink) {
      return {
        postExists: true,
        _id: postWithSameLink._id
      }
    }

    var user = Meteor.user();
    var post = _.extend(postAttributes, {
      userId: user._id, 
      author: user.username, 
      submitted: new Date()
    });

    var postId = Posts.insert(post);

    return {
      _id: postId
    };
  }
});

如果我們到此為止，這個演示就不那么有意義。當(dāng)前，看起來就像是帖子表單提交后暫停了5秒鐘，然后轉(zhuǎn)到主帖子列表，沒發(fā)生其他事情。

為了理解這是為什么，讓我們看看帖子提交的事件 handler：

Template.postSubmit.events({
  'submit form': function(e) {
    e.preventDefault();

    var post = {
      url: $(e.target).find('[name=url]').val(),
      title: $(e.target).find('[name=title]').val()
    };

    Meteor.call('postInsert', post, function(error, result) {
      // display the error to the user and abort
      if (error)
        return alert(error.reason);

      // show this result but route anyway
      if (result.postExists)
        alert('This link has already been posted');

      Router.go('postPage', {_id: result._id});  
    });
  }
});

我們在方法 call 回調(diào)函數(shù)中放了 Router.go() 路由函數(shù)。

現(xiàn)在的行為通常是正確的。畢竟，你不能在確定他們帖子提交是否有效之前去跳轉(zhuǎn)用戶，只是因?yàn)槿绻⒓刺D(zhuǎn)走，然后幾秒鐘后再轉(zhuǎn)回到原始帖子頁面去更正數(shù)據(jù)，這會非常令人困惑。

但是對于這個例子而言，我們想立即看看結(jié)果。所以我們將路由更改到 postsList 路由（我們還不能路由到帖子，因?yàn)樵诜椒ㄖ馕覀儾恢捞拥?_id），把它從回調(diào)函數(shù)中移出來，看看會發(fā)生什么：

Template.postSubmit.events({
  'submit form': function(e) {
    e.preventDefault();

    var post = {
      url: $(e.target).find('[name=url]').val(),
      title: $(e.target).find('[name=title]').val()
    };

    Meteor.call('postInsert', post, function(error, result) {
      // display the error to the user and abort
      if (error)
        return alert(error.reason);

      // show this result but route anyway
      if (result.postExists)
        alert('This link has already been posted');
    });

    Router.go('postsList');  

  }
});

如果我們現(xiàn)在創(chuàng)建一個帖子，我們可以清楚地看到延遲補(bǔ)償。首先，插入一個標(biāo)題帶 (client) 的帖子（列表的第一個帖子，鏈接到 GitHub）：

接著，五秒之后，它就會被服務(wù)器插入的真正帖子文檔所替代：

客戶端集合內(nèi)置方法

通過上面所說的，你可能會認(rèn)為內(nèi)置方法很復(fù)雜，但事實(shí)上它們也可以相當(dāng)簡單。實(shí)際上我們已經(jīng)用過三個非常簡單的內(nèi)置方法：集合的操作方法 insert、update 和 remove。

當(dāng)你定義一個服務(wù)器集合稱為 'posts' ，你已經(jīng)隱式地定義了這三個內(nèi)置方法： posts/insert、posts/update 和 posts/delete。換句話說，當(dāng)你在本地集合中調(diào)用 Posts.insert()，你已經(jīng)在調(diào)用延時補(bǔ)償方法來做下面這兩件事：

1. 檢查我們是否允許通過調(diào)用 allow 和 deny 方法的回調(diào)去操作集合（然而這并不需要發(fā)生在內(nèi)置方法的模擬）。
2. 實(shí)際地修改底層的數(shù)據(jù)庫。

內(nèi)置方法的相互調(diào)用

你可能已經(jīng)意識到當(dāng)我們插入帖子的時候，post 的內(nèi)置方法調(diào)用了另一個內(nèi)置方法（posts/insert）。這是如何工作的呢？

當(dāng)模擬方法（客戶端版本的內(nèi)置方法）開始運(yùn)行，模擬方法執(zhí)行 insert（插入的是本地集合）時，我們不叫它真正的服務(wù)器端 insert，但我們會認(rèn)為服務(wù)器端的 post 也將會同樣的被插入。

因此，當(dāng)服務(wù)器端的 post 調(diào)用內(nèi)置方法 insert 的時候更加沒有必要去擔(dān)心的客戶端模擬方法，它肯定能夠在客戶端順利地插入。

像之前一樣，在閱讀下一章之前，不要忘記還原你所做的更改。