Clojure / Clojurescript 中的客户端/服务器反应式同步答案

【问题标题】：Client / server reactive sync in Clojure / ClojurescriptClojure / Clojurescript 中的客户端/服务器反应式同步
【发布时间】：2019-03-25 15:15:45
【问题描述】：

有没有一种惯用的方法来使用 Clojure 和 Clojurescript 在浏览器和服务器之间进行反应式数据同步？一种技术与另一种技术的优缺点是什么？

过去曾使用过 Meteor.js，这种反应式数据库同步比手动编写路由和轮询更新更可取。发布/订阅系统允许 Web 开发人员编写更少的样板代码来移动数据。 Clojure 似乎很适合这种技术。我一直无法确定这是否是 clj/cljs 生态系统中已解决的问题。

【问题讨论】：

SO 不赞成这样宽泛的问题。但这并不意味着您的问题是错误的/不好的。
嗯，我并不打算将问题广泛化。我在询问使用一组特定工具的特定技术。搜索有关该主题的信息很少，因此我希望从这里的专家那里获得输入，这将为像我这样使用 clj/cljs 搜索有关数据同步的信息的其他人提供价值。
你看，每个人都有自己特定的工具集。这使得这个问题的答案成为一个见仁见智的问题。
我不太明白你的意思。是的，人们可能对解决这个问题的最佳方法有意见，但 IMO 独立于询问可能的解决方案是什么（或者它们是否存在）。无论如何，我已经编辑了我的问题以试图澄清。
我没用过 Meteor，但你显然可以使用 XHR 和 WebSockets 以异步方式从后端到前端进行通信，然后在前端使用 Reagent 或其他基于 React 的库进行渲染跨度>

【解决方案1】：

简短的回答是“不”。

我在生产中使用过 Meteor.js，并且在进入 CLJ(S) 时也使用过相同的东西。我所知道的最接近的是：

Datsync
- 使用 Datomic 和 Datoms 作为同步协议
- 似乎是阿尔法
Fulcro
- 有助于乐观更新，但不像 Meteor 与 Minimongo 那样直接数据同步，更接近 Meteor 方法（即同一调用的客户端和服务器实现）
- 生产就绪，广泛使用

为什么 CLJ(S) 中没有写流星杀手？

很难做到（完全，性能上）
- Meteor 背后的公司在过去十年中提出了 tens of millions of dollars 在该领域的工作，但仍未解决数据同步设计中的所有可扩展性或语义粗糙问题
- 人们倾向于使用 Clojure 的数据存储（Datomic 或关系）可能会使数据同步更加困难，而且肯定有很大不同（它不会是 Meteor 实现的一个端口）。
Clojure 开发人员倾向于围绕特定问题/解决方案/要求组装系统，而不是围绕特定功能/框架组装解决方案（例如，同步全栈的 Mongo 文档）。

尽管如此，无论是在 Clojure 社区内部还是外部，人们仍在思考这个问题。签出：

唯一有意义的比较方法是在您的上下文中考虑它们。我记得当时放弃 Meteor 的魔法感觉很重要，但还没有发现自己想要回去。我将其视为简单性和灵活性的交易魔术。

【讨论】：