实时的Web应用程序:socket.io或托pipe的数据/消息?

CONTEXT

应用程序:单页实时networking应用程序

function:

  • 用户操纵应用上的小部件,发送到服务器的小部件数据
  • 服务器使用工作线程计算并将数据发送回应用程序

通讯:

  • types:目前只有应用程序< – >服务器。
  • 将来需要pub / sub
  • 大小:每个更新JSON几个kB任何一种方式
  • 频率:每分钟更新1-10次

高峰负载:几百个并发用户(但当然)

开发者能力:麻瓜


方法

1)天真的做法:托pipenode.js + express + socket.io

我有一个沙箱与天真的方法运行良好,但我觉得像驾驶猫(我告诉你,他可以开车!只是不是很好!)。 我的头盔上的csp,xframe,xss等,但我的socket.io代码是非常基本的,没有特别的事件处理程序或stream量限制。

2)备用方法:托pipenode.js +托pipe的实时数据/消息服务

这里的期望是,托pipe的实时数据/消息服务是健壮的,可以扩展到stream量,除了处理像DoS和安全传输的问题。 托pipe的node.js应用程序将在CDN后面提供静态文件,因此主要处理实时数据和工作线程。 node.js应用程序不会直接面对Web应用程序用户。


你会推荐方法#2明显优越,值得额外的成本?

任何其他意见/build议welome。

晚会有点迟,但我认为这对其他人也有帮助。 实质上,您必须评估您pipe理支持实时Web应用程序的堆栈的能力,也就是说您是否可以configuration所有组件(socket.io,express,node)并使其保持运行?

通过使用一个简化了一些事情的框架,您可以让自己的生活更轻松。 meteor( https://www.meteor.com/ )是一个很好的例子,可以让你更专注于代码。 您仍然需要一些知识来部署Meteor,但是这需要一些工作量。

在极端的情况下,你可以select一个完全托pipe的框架,比如Sync Ninja( http://www.syncninja.com/ ),它可以让你只处理你的代码。

从经验来看,在刚开始的时候使用托pipe解决scheme是值得的,因为您可以专注于构build应用程序而不是pipe理后端。

免责声明:我曾在同步忍者。

    Interesting Posts