top | item 7640473

DataScript – Datomic in ClojureScript

143 points| sgrove | 12 years ago |github.com

34 comments

order
[+] drcode|12 years ago|reply
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?

[+] davidrupp|12 years ago|reply
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.
[+] tony_landis|12 years ago|reply
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.
[+] dustingetz|12 years ago|reply
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.
[+] mvzink|12 years ago|reply
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.
[+] imslavko|12 years ago|reply
Not familiar with Datomic. Does it mean now you can reuse querying code on the server to real Datomic and on the client (in browser) to DatomicScript?

If so, it could lead to some features like latency compensation and stubs similar to Meteor's MongoDB and MiniMongo. That would be cool.

[+] tonsky|12 years ago|reply
Yes, query language is almost identical.
[+] sethev|12 years ago|reply
This looks like a very interesting project although it's a bit confusing that it's named after a proprietary database.
[+] ibdknox|12 years ago|reply
Why is it confusing? It's a basic port of that proprietary database to JavaScript. It's not like it's something completely unrelated.
[+] sdegutis|12 years ago|reply
Looks great. I could see using this for some data crunching client-side, maybe even in conjunction with something like graph.js.
[+] jchrisa|12 years ago|reply
Are there any examples of using this from a JavaScript-mostly app? I can see it being useful as a way to clean up existing "global variable" apps.
[+] tonsky|12 years ago|reply
There isn’t—yet—but it’s a popular request and I’m now thinking it could be made accessible from JS pretty easily
[+] gcv|12 years ago|reply
Curious: why is this limited to ClojureScript? I can see this being useful in JVM Clojure in projects which do not need real or full Datomic.
[+] coolsunglasses|12 years ago|reply
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.
[+] Skinney|12 years ago|reply
From what I can see, DataScript is in-memory only. Wouldn't that be the same as downloading Datomic-free and creating an in-memory db?
[+] dj-wonk|12 years ago|reply
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.
[+] dj-wonk|12 years ago|reply
How about "NotDatJS" (short for the "Not Datomic" JS Database)?