Node.js+Socket.io：模板化@服务器还是浏览器？通过 ajax 或 socket.io 加载内容？答案

【问题标题】：Node.js+Socket.io: Templating @ server or browser? Load content via ajax or socket.io?Node.js+Socket.io：模板化@服务器还是浏览器？通过 ajax 或 socket.io 加载内容？
【发布时间】：2011-12-23 05:18:04
【问题描述】：

我已经问过一个类似的问题，但这个问题有点不同/具体：

我即将开始开发一个社交社区网站（针对本地用户组），它具有时间线、IM/聊天、论坛等功能......

Node.js 和 socket.io（或 now.js）在后端。前端的 jQuery（可能还有bone.js 或类似的）。内容通过 socket.io 或 ajax 加载，并通过 url hash 进行导航。

有两件事我无法决定走哪条路。我希望这里有一些人可以提供一些好的或坏的经验。

在服务器或浏览器中进行模板化？我不确定是否最好为时间线、论坛帖子、IM/聊天等加载完整的 html 站点 + 实时更新（也在 html 中），或者通过 ajax 或 socket.io 使用类似 REST api 的东西并执行客户网站上的模板。我以前从来没有这样做过。您需要下载模板等。有没有人有这方面的经验？还有 2 种方法可以实现类似 rest 的 api：例如请求一个论坛帖子，然后请求与该帖子关联的用户等等（就像服务器端 MVC） - 或者 - 请求一个论坛帖子，服务器会回答所有需要的信息。
通过 ajax 或 socket.io 加载内容？我肯定会使用 socket.io 或 now.js 进行实时通信（IM、聊天）和 pubsub（在主页上 -> 订阅新的时间线更新，在论坛主题上 -> 订阅新帖子）。但是我是否也应该通过套接字加载 HTML（或提供类似 REST 的 API，请参阅问题 1）？当人们在选项卡中打开论坛帖子时（我通常会这样做），这意味着很多套接字连接。而且我不确定 websocket 建立连接需要多长时间。

所以有 4 种方法可以做到这一点：

通过 AJAX 的 HTML - 可能是最稳定的方式，不需要大量的 javascript 来做模板 - 浏览器可以使用开放的 HTTP 连接来请求内容。
通过 socket.io 的 HTML - 必须建立 websocket 才能加载内容（可能更慢）
API 通过 AJAX - 因为它可能需要更多请求作为通过 AJAX 的 HTML 可能会有一些 HTTP 标头开销 + 您需要在每个请求中进行身份验证 - 我不是太多 ajax 请求的朋友。
通过 socket.io 的 API - 套接字只能被验证一次，并且您可以即时请求 API 对象。但是，我仍然会通过 HTTP 加载模板和 js 以进行浏览器缓存。

我知道这是一个巨大的帖子，但我现在已经争论了很多天，只是无法决定，因为一旦开始开发就切换系统需要做很多工作。这不是一个公共项目，它仅限于约 10k-15k 当地人，因此不能那么完美，在我看来，这是一个学习新事物的好机会（我对 node 完全陌生，经典的 PHP MVC + jquery dev 在这里）。

【问题讨论】：

标签： node.js backbone.js express socket.io

【解决方案1】：

我认为你应该在后端使用 RESTful api，让模板只发生在前端（可能使用 Backbone），并且只将 Socket.IO 用于实时内容（例如聊天）。将 websocket 用于加载 HTML 之类的事情没有任何意义，因为它很可能永远不会改变。

所以我的投票是：

1) 通过 AJAX 生成 HTML
2) API 通过 AJAX
3) 实时通信，例如通过 Socket.IO 的聊天消息（或其他不断变化的东西）

【讨论】：

除了加载所有 javascript 的入口/索引页面外，没有静态 HTML（完全基于用户内容）。论坛示例：加载 HTML（线程列表、帖子）并显示它们，或通过 API 加载 json（线程列表作为线程对象数组，线程作为帖子对象数组）并在前端呈现。如果我选择使用 API 方式，我认为最好通过 socket 访问 API，没有 headers，没有 cookie。
好吧，如果该内容经常更改并且您希望让用户保持更新，我将通过 2 种方式实现这一点：1) 使用 api 从数据库中获取最后 X 个帖子等 2) 保留他使用 Socket.IO 由第二个更新

【解决方案2】：

虽然真的没有一个确定的答案，这要看情况而定。

如果您需要搜索引擎可抓取，您可以不仅依赖客户端处理。如果您的个人视图很轻，和/或您需要支持移动设备，您应该在服务器端进行初始渲染。

目前，我建议使用您的客户端应用程序和服务器端都可以使用的 API。如果您使用 node 进行服务器端渲染，您可以重用许多相同的逻辑，包括 API 客户端。

再往前走几步，如果您从 github 上的 Yahoo Flux 示例项目开始，您可以在客户端和服务器端使用相同的逻辑，包括使用 React 视图进行渲染。这不是一个简单的解决方案，并且需要一些工作。

对于交互式元素，服务器端渲染可以最小化，因为当客户端启动您的聊天/即时消息位时，您的商店会通过 sockjs/socket.io 推送事件连接。

当涉及跨多个进程运行时，您会遇到可伸缩性问题，并且可能需要一个由数据库支持的发布/订阅链来延长重新连接周期或错过 IM 消息。没有灵丹妙药。

现在，我喜欢flux+react...当Angular2出来时，它可能有一个更好的服务器端渲染故事。

【讨论】：