有一段时间，我们在 RabbitMQ 总部一直在努力寻找一种在 Web 浏览器中公开消息传递的良好方法。过去，我们尝试过许多方法，从著名的 JsonRPC 插件（它基本上通过 AJAX 公开 AMQP）到 Rabbit-Socks（创建通用协议中心的尝试），再到管理插件（可用于基本操作，例如从浏览器发送和接收消息）。
随着时间的推移，我们了解到 Web 上的消息传递与我们过去习惯的非常不同。我们的所有尝试都没有真正解决这个问题，而且 Web 上的消息传递可能在一段时间内还不会成为一个完全解决的问题。
也就是说，RabbitMQ 用户一直都在询问一件简单的事情，尽管它并不完美，但它绝对不是在浏览器中进行消息传递的最糟糕方法：通过 WebSockets 公开 STOMP。
或者：如何在 WebSockets 或 SockJS 上正确进行多路复用
如您所知，WebSockets 是一项很酷的 HTML5 技术，它允许您异步发送和接收消息。我们的兼容层 - SockJS - 模拟它，即使在旧浏览器或代理后面也能正常工作。WebSockets 在概念上非常简单。API 基本上是：连接、发送和接收。但是如果您的 Web 应用程序有多个模块，并且每个模块都想要发送和接收数据呢？
AtomizeJS 是一个用于编写分布式程序的 JavaScript 库，这些程序在浏览器中运行，无需在服务器上编写任何特定于应用程序的逻辑。
在 RabbitMQ 总部，我们花了相当多的时间争论。偶尔，我们会讨论一些重要的事情，比如“消息传递”的真正含义以及可以用于实现“消息传递”的不同 API 的范围。RabbitMQ 和 AMQP 为消息传递提供了一个非常明确的接口：您拥有“发送”和“接收”动词，并且需要考虑您的消息传递模式是什么。在引擎盖下发生了很多（通常非常巧妙的）事情，但尽管如此，该接口仍然相当低级且明确，这提供了相当大的灵活性。但有时，这种 API 样式并不适合您要解决的问题的最佳匹配 - 您真的会陷入僵局并想“我在这里需要的是 AMQP 消息代理”，或者您会根据先前的知识意识到您可以选择使用 AMQP 消息代理来解决当前的问题？
我们想知道如何向更广泛的受众展示 SockJS 及其可能性。拥有一个工作演示比解释 枯燥理论 有价值得多，但如果您只是一个没有设计技能的无聊技术人员，您能展示什么呢？
对于这样的问题，打开一本历史书并回顾一下上一代没有艺术技能的计算机极客总是一个好主意。他们在做什么？在带有绿色字母的控制台上，他们玩着极客的电脑游戏，MUD（多人地下城） 特别受欢迎。
嘿，我们也可以做到！
最近，Web 技术领域发生了一些很热的事情。JavaScript 似乎正在担当重任，无论是在浏览器端还是在服务器端。在 RabbitMQ 总部，我们对消息传递的广阔世界中的发展很感兴趣，我们对消息传递的 JavaScript 角度特别兴奋 - 主要是 WebSockets 和相关技术。
有人要求我在 PubSubHuddle 会议 上做简短的演讲。演讲内容是关于 WebSockets 的当前发展、问题以及使用它们构建 Web 应用程序。
WebSocket 技术正在赶超，但所有浏览器都支持它还需要一段时间。与此同时，有很多项目旨在替代 WebSockets 并为 Web 应用程序启用“实时”功能。但所有尝试都只解决了通用问题的一部分，并且没有一种单一解决方案可以工作，可扩展且不需要特殊的部署技巧。
使用 Web 浏览器进行“实时 Web”或消息传递的想法已经存在很长时间了。首先它被称为“长轮询”，然后是“Comet”，最新的化身被称为“WebSockets”。毫无疑问，它正在朝着好的方向发展，WebSockets 是一项非常棒的技术。
但在为实时功能而战的过程中，我们忽略了真正重要的是如何实际使用消息传递。在 Web 上下文中，一切都由请求响应驱动，将典型的 Web 堆栈与异步消息传递结合起来并不容易。
