Looks like a great library... It would be intriguing to try to use something like DatomicScript for the app state of an Om application.
(Edit: Read in a separate blog post that the author of DatomicScript is thinking about this already)
At the end of the day though, I still think someone (smarter than me) needs to figure out the full end-to-end solution for datomic+clojurescript, with both client and server elements.
The core question: Does it make sense to map datomic to a REST API on the server, then consume the REST on the client? Or, does it make more sense to build something more clojure-like for the client-server interface, and remove REST from the equation entirely?
Datomic is bundled with a REST server: http://docs.datomic.com/rest.html. And it includes an endpoint to subscribe to a stream of Server-Sent Events, which lets you drink from the transaction-report firehose. But there is a lot of data in that stream. I'm writing a production Pedestal app, and I could definitely use the capability to store my data on the client in the same shape as Datomic and query it with Datalog.
A seamless datomic <-> clojurescript client/service framework is needed. I am just getting started with Om and hope to experiment with some ideas in that space. I don't think REST is the right approach. I would like to abstract everything to an AVET or sequence thereof.
i think you want the application-facing interface to remain REST (links between entities, HATEOAS), but the REST/CRUD client's transport layer wouldn't be traditional http/ajax, rather implement similar capabilities to a Datomic Peer. So a CRUD READ would query a cached Datomic index rather than touch network. Create, Update, Delete could be http/ajax or could be something else like a websocket; I believe transport to be orthogonal to the fundamental principles of REST application design.
Interesting, I get the feeling though that RH also thinks this isn't the right approach, that some more though needs to be put into the client-server interface still that goes beyond vanilla datomic.
Thing is, server-side Datomic peers work in trusted env; every peer sees everything. As you start doing something like a peer in every browser that opens your app, you need to provide it only with the part of the database. This filtering should be done two-way (what’s allowed to read, what’s allowed to push back) and is not very straightforward thing to do. It’s not even clear how this thing should be configured. Also server-side lazy loading model won’t work in JS — queries will become async. Given that, server-client communication layer can be implemented, I guess, but it won’t look like anything like vanilla Datomic peer.
Exciting prospect. How about DataScript for your app state + tx-listen/om-sync mirroring transactions? Might require wrapping the datascript/transact! call, and I haven't thought about reading from the cliente. Maybe as simple as lazily mirroring datascript/q calls and filling those back into the DataScript map.
In the same way that OracleScript would be an odd choice of name for a SQL database implemented in JavaScript. Now that I say that, though, I guess there isn't really a name for what Datomic is except Datomic.
Why even limit it to Clojure and ClojureScript? I could use this from JavaScript or PureScript as an immutable local store to replicate/merge with the backend asynchronously.
It was commited accidentally. Yes, it may be translated to clojure. However, I still don’t know if I should do it, given we have in-memory db bundled with Datomic free client jar.
How about another rename? DatomicScript was clearly a bad idea and possibly infringing. "DataScript" is just misleading. Using "_____Script" creates the appearance that is a scripting language. Perhaps "_____DB" or "_____JS" would be better.
(Edit: Read in a separate blog post that the author of DatomicScript is thinking about this already)
At the end of the day though, I still think someone (smarter than me) needs to figure out the full end-to-end solution for datomic+clojurescript, with both client and server elements.
The core question: Does it make sense to map datomic to a REST API on the server, then consume the REST on the client? Or, does it make more sense to build something more clojure-like for the client-server interface, and remove REST from the equation entirely?