1
votes

Is there an idiomatic way to do reactive data synchronization between browser and server with Clojure and Clojurescript? What are the pros and cons of one technique vs another?

Having used Meteor.js in the past this sort of reactive database sync is highly preferable to manually writing routes and polling for updates. A pub/sub system lets web developers write less boilerplate code to move data around. Clojure seems like it would be a natural fit for such a technique. I have been unable to determine if this is a solved problem in the clj/cljs ecosystem.

1
SO does not approve of such broad questions. It does not mean that your question is wrong/bad, though.akond
Hmm I did not intend the question to be broad. I am asking about a specific technique using a specific set of tools. Searching for information about the topic revealed little so I hoped to get input from experts here that would provide value to others like myself searching for information about data sync using clj/cljs.imagio
You see, every person has his own specific set of tools. And that makes an answer to this question a matter of opinion.akond
I don't quite understand what you mean. Yes people may have opinions about what is the best way to solve this problem but IMO that is independent from asking what the possible solutions are (or if they even exist). Regardless I have edited my question in an attempt to clarify.imagio
I haven't used Meteor, but you could obviously use XHR and WebSockets to communicate in an asynchronous fashion from backend to frontend, and then Reagent or other React-based libs on the frontend for renderingAlan Thompson

1 Answers

4
votes

The short answer is "no".

I've used Meteor.js in production, and also looked for the same when getting into CLJ(S). The closest I'm aware of are:

  • Datsync
    • Uses Datomic and Datoms as the sync protocol
    • Seems to be alpha
  • Fulcro
    • Has help for optimistic updates, but not direct data sync like Meteor has with Minimongo, closer to Meteor methods (ie a client and server implementation of the same call)
    • Production-ready, widely used


Why hasn't a Meteor-killer hasn't been written in CLJ(S)?

  • It's hard to do (at all, performantly)
    • The company behind Meteor raised tens of millions of dollars over the last decade to work in this space and still didn't resolve all the scalability or semantic rough edges in the data sync design
    • The datastores Clojure people tend to use (Datomic or relational) likely make data sync even harder, and certainly quite different (it wouldn't be a port from Meteor's implementation).
  • Clojure developers tend to prefer assembling a system around the needs of a particular problem/solution/requirement rather than assembling a solution around a particular feature/framework (eg Mongo documents that sync full-stack).

People are still thinking about this though, both inside the Clojure community and out. Check out:

The only meaningful way to compare is to consider them both in your context. I remember giving up Meteor's magic felt significant at the time but haven't found myself wanting to go back. I see it as trading magic for simplicity and flexibility.