3 ms·

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 separa

by drcode 13y ago

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?

tony_landis 13y ago
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.
vdm 13y ago
https://twitter.com/richhickey/status/355394063165440000 https://twitter.com/richhickey/status/355394063165440000
- drcode 13y ago
  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.
  - tonsky 13y ago
    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.
dustingetz 13y ago
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 13y ago
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.
davidrupp 13y ago
Datomic is bundled with a REST server: http://docs.datomic.com/rest.html 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.

by drcode 13y ago

tony_landis 13y ago

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.

vdm 13y ago

https://twitter.com/richhickey/status/355394063165440000 https://twitter.com/richhickey/status/355394063165440000

drcode 13y ago
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.
- tonsky 13y ago
  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.

dustingetz 13y ago

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 13y ago

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.

davidrupp 13y ago

Datomic is bundled with a REST server: http://docs.datomic.com/rest.html 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.