AtomizeJS：分布式软件事务内存

AtomizeJS 是一个 JavaScript 库，用于编写分布式程序，这些程序在浏览器中运行，而无需在服务器上编写任何应用程序特定的逻辑。

在 RabbitMQ 总部，我们花了很多时间争论。 偶尔，争论的是重要的事情，例如消息传递的真正含义，以及可用于实现消息传递的不同 API 的范围。 RabbitMQ 和 AMQP 提供了一个非常明确的消息传递接口：你确实有动词发送和接收，并且你需要考虑你的消息传递模式是什么。 在幕后有很多（通常是非常聪明的东西）在进行，但尽管如此，该接口仍然是相当低级且明确的，这提供了很好的灵活性。 然而，有时，这种 API 风格并不是最适合你尝试解决的问题——你真的会陷入僵局并思考“我这里需要的是一个 AMQP 消息代理”，还是你从预先存在的知识中意识到你可以选择使用 AMQP 消息代理来解决你当前的问题？

AtomizeJS 存在于频谱的另一端。 涉及大量消息传递，但你几乎看不到任何消息传递。 相反，你用 JavaScript 编写事务来修改对象，这些对象在连接到同一 AtomizeJS 服务器的所有客户端之间共享。 你获得的 API 允许你做比你习惯的数据库事务更强大的事情，特别是，retry 允许你中止事务，然后在其他人更改了你读取的变量之一后自动重启它。 这意味着你拥有观察者模式，并且由此你可以构建任何你想要的显式消息传递模式。 在大多数情况下，我怀疑你会构建声明发送或接收的 API，相反，你将构建更丰富的数据结构——工作队列、共享字典等。 那么要提出的问题是：基于 AtomizeJS 提供的类似事务的 API，还是基于 RabbitMQ 和 AMQP 代理提供的显式消息传递 API，构建这些东西更容易？ 没有一种万能的解决方案，具体问题具体分析等等，但请在下方留下你的想法。

AtomizeJS 提供的优势不在于从浏览器中使用 STM，而在于针对分布式对象使用 STM。 这允许你在浏览器之间轻松共享状态，以直观的方式安全地修改它，从而构建你的应用程序，几乎不需要或根本不需要应用程序特定的服务器端代码。 目前，在不支持前沿 JavaScript 功能的浏览器中使用起来有点笨拙（尽管我提供了一些工具来尝试缓解这种情况），并且所有功能都适用于最新版本的 Chrome、Firefox、IE、Safari 和 Opera。 请试用一下，并告诉我们你的想法！