用于后台处理的Websockets
使用Websockets（comet，server push，…）来克服长时间运行的HTTP请求的问题是一个好主意吗？ 想象一下，你有一个应用程序，build立在全栈Web应用程序框架，如Django或Rails。 你想以表演的名义做一些后台处理。 从程序员的angular度来看，这很容易做到，但问题出现在UI中。
用户需要立即响应。 所以我的想法是使用Socket.IO + node.js + AMQP消息传递，在后台任务完成后将通知推送回浏览器。 我喜欢这个想法，但是它仍然感觉像很多工程，只是因为我们不想在我们的主应用程序中长时间运行请求。 竞争的想法可能是使用另一个更强大的Web服务器，它可以处理许多长时间运行的HTTP请求。
你认为哪一个更好？
使用Websockets解决长时间运行的HTTP请求的问题是一个好主意吗？
是的。 与其他技术（如连续或长时间轮询）相比，您可以节省大量的数据。 试着看这篇文章 ，即步骤3的一部分。
我喜欢这个想法，但是它仍然感觉像很多工程，只是因为我们不想在我们的主应用程序中长时间运行请求。 竞争的想法可能是使用另一个更强大的Web服务器，它可以处理许多长时间运行的HTTP请求。
Socket.io为你抽象传输层和后备解决scheme（在没有web套接字的情况下）。 如果你只想使用socket.io/node.js/AMPQ栈进行消息传递和通知，那么它不应该是一个复杂或耗时的开发过程，但是它可能取决于各种各样的东西。
通过将消息/通知委托给node.js，您可以在很大程度上减轻您的主应用程序，因为它的非阻塞体系结构尽pipe您将引入对另一种技术的依赖。
另一方面，select性能更高的Web服务器可能会在一段时间内解决您的性能问题，但最终可能会缩小您的系统（无论是启动还是停止）。
WebSockets本身在这里提供一些例如XHR或jsonp长轮询。 从用户的angular度来看，任何一种传输方式的消息传递都是一样的。 从服务器的angular度来看，一个开放的WebSocket连接或一个开放的长轮询并不是非常不同的。
你真的在做什么，而且应该做什么，不pipe底层技术如何，build立你的应用程序是asynchronous的 – 事件驱动的。