Backbone.sync – 使用 ajax 以及 Socket.IO/WebSockets 的集合答案

【问题标题】：Backbone.sync – Collection using ajax as well as Socket.IO/WebSocketsBackbone.sync – 使用 ajax 以及 Socket.IO/WebSockets 的集合
【发布时间】：2013-03-14 14:27:13
【问题描述】：

我有一个 Backbone 应用程序，它有一个名为 Links 的集合。 Links 映射到 /api/links 的 REST API URI。

API 将为用户提供最新链接。但是，我有一个系统，当用户点击这个 API 时，它会向消息队列添加一个作业，请求更新数据库中的链接。

当这项工作完成后，我会推送到 Backbone 集合的新链接。

我应该怎么做？在我看来，我有两个选择：

从 Backbone 集合中，长轮询 API 以获取新链接
设置 WebSockets 以在作业完成时向集合发送“消息”，同时发送新数据
为我的应用程序废弃 REST API，只为所有内容使用 WebSocket，因为我以后可能会有更多的实时需求

带有 REST API 的 WebSockets

如果我使用 WebSockets，我不确定将它集成到我的 Backbone 集合中以便它与 REST API 一起工作的最佳方法。

目前我的 Backbone 收藏看起来像这样：

var Links = Backbone.Collection.extend({
  url: '/api/links'
});

我不确定如何启用 Backbone 集合来处理 AJAX 和 WebSocket。我是否继续使用默认的 Backbone.sync 进行 CRUD Ajax 操作，然后手动处理单个 WebSocket 连接？在我看来：

var Links = Backbone.Collection.extend({
  url: '/api/links',
  initialize: function () {
    var socket = io.connect('http://localhost');
    socket.on('newLinks', addLinks)
  },
  addLinks: function (data) {
    // Prepend `data` to the collection
  };
})

问题

我应该如何根据上述选项或您的任何其他想法来实现我的实时需求？请提供代码示例以提供一些上下文。

【问题讨论】：

你见过这个吗？ github.com/logicalparadox/backbone.iobind
@PaulHoenecke 我有，但我不确定如何首先通过 WebSockets 制作集合“获取链接”，然后当有更多可用时（当工作完成时），“获取更多链接。”如果你得到我？ Backbone.ioBind 似乎将 CRUD 操作映射到 Sockets，但我仍然不确定我的集合将如何寻找我的用例（在原始帖子中描述）。
@PaulHoenecke 刚刚意识到我应该如何使用文档中显示的serverChange 方法来做到这一点。但是，这意味着我需要将整个 API 转移到 WebSockets。这是好事吗？！
不确定您是否需要。如果您不使用替换 sync，您可以继续使用 REST API 进行普通 CRUD。然后侦听您从服务器发出的一些套接字事件，并可能调用myCollection.update(dataFromSocket)，其中myCollection 以前是通过REST 使用正常获取同步的。

标签： api rest backbone.js websocket socket.io

【解决方案1】：

不用担心！ Backbone.WS 为您服务。

你可以像这样初始化一个 WebSocket 连接：

var ws = new Bakcbone.WS('ws://exmaple.com/');

然后像这样绑定一个模型：

var model = new Backbone.Model();
ws.bind(model);

然后此模型将侦听 ws:message 类型的消息事件，您可以调用 model.send(data) 通过该连接发送数据。

当然，集合也是如此。

Backbone.WS 还提供了一些工具，用于将自定义的类似 REST 的 API 映射到您的模型/集合。

【讨论】：

【解决方案2】：

我的公司有一个使用主干的完全基于 Socket.io 的解决方案，主要是因为我们希望我们的应用程序在另一个用户屏幕上实时进行更改时“更新”gui。

简而言之，它是一罐蠕虫。 Socket.IO 运行良好，但它也打开了很多你可能不感兴趣的门。骨干事件变得非常不正常，因为它们与 ajax 事务紧密相关……您实际上是在覆盖该默认行为。我们更好的问题之一是删除，因为我们的套接字响应不是改变的模型，而是整个集合，例如。我们的解决方案确实比大多数解决方案走得更远，因为事务是通过一个 DDL 进行的，该 DDL 专门设置为在我们现在和将来需要能够与之通信的许多设备上通用。

如果您确实走 ioBind 路径，请注意，与非套接字流量相比，您将使用不同的方法来更改事件（如果您混合和匹配）这是该方法的最大缺点，标准的东西，例如“更改" 变成 "update" 例如为了避免冲突。在深夜调试或有新开发人员加入团队时，它会变得非常混乱。出于这个原因，我更喜欢使用套接字，或者不使用，而不是组合。到目前为止，套接字一直很好，而且速度快得吓人。

我们使用一个基础函数来完成繁重的工作，并有几个其他函数扩展了这个基础，为我们提供了我们需要的交易功能。

This article 为我们使用的方法提供了一个很好的开端。

【讨论】：