I've had such a blast with re-frame & storing app-db in localStorage (per the re-frame todomvc example), and doing just a small handful of things on the backend. But it's time to add persistent storage on the backend for safety and so that others can interact with the data collaboratively. And the thought of somehow pushing every app-db change to a backend, coordinating other users' changes, deconflicting, all just seems like so much horribleness… is there anything that makes all that pile of 💩 as easy as re-frame makes frontend reactive programming?

Is Datomic The Answer??? 😄

@fasiha: i don't think Datomic handles client-server interaction. Maybe if you need this process to be transparent you should look at something like PouchDb. However i guess change and conflict coordination is better handled by hand (probably because i actually haven't tried smart syncing tools). If you wan't reactivity there's also RethinkDb

However i'm really interested in what others think about that because client-server communication is often a point of frustration for me.

I'll revisit RethinkDB because I enjoyed using it as a standalone db (didn't use its changefeed features which I'm sure have matured in the last year or so)

Re-frame in my experience can hold its own on the frontend but I can start seeing why some of the ideas from Relay/Falcor/Om Next are the next horizon, e.g., unified local (app-db) queries and remote queries

@fasiha: we’re using RethinkDB with re-frame, and think we have a pretty neat solution for client server queries

Not sure when we can share our findings, but you can see some of it at https://github.com/Day8/re-frame/wiki/Subscribing-To-A-Database

@danielcompton: ah, thanks for reminding me about this. I stopped looking at it because I have been heretically putting all my XHRs in handlers (in response to events like clicks) instead of views, but I can see it is time to revisit the role of views in making requests. Do you use RethinkDB changefeeds?

Our design uses them, but we’re still building it

Why is Reagent's make-reaction used here: https://github.com/Day8/re-frame/wiki/Subscribing-To-A-Database#some-code, and with a function? Instead of re-frame's reaction? Is the idea that the subscription won't return anything until it's changed by the handler upon receipt of remote data? Is that what make-reaction does?

@fasiha: reaction is reagent's macro as well - syntactic sugar over make-reaction (https://github.com/reagent-project/reagent/blob/master/src/reagent/ratom.clj#L5). I don't think it supports :on-dispose so make-reaction was used.

And subscription will return nil (or whatever, before real data arrived) as well. Otherwise it would block UI thread i guess which isn't a good idea.

ccccccdltdlveerjbtchglvvuejvcvjchfivnkjekfjn

@fasiha @nidu I am experimenting with approach like: forward some re-frame events to server via WebSocket, process them in by ‘re-frame like’ handlers on server by applying some transactions to datomic db, then a separate go-loop on server is listening to datomic transactions and pushes one or more re-frame events on one or more connected clients. Not sure if approach like this is already implemented in some ready-to-use lib, so I am giving it a shot here: https://github.com/drapanjanas/pneumatic-tubes

@drapanjanas: what do you mean by re-frame like handlers? Functions which take entire state and action and return modified state?

Not exactly, the datomic transactions are side effects. The handler returns a new state of data associated with the client connection. This data is intended to be used for selecting clients by some predicate to dispatch events to multiple clients. Also the input event vector of handler is like in re-frame.

But perhaps it would be possible to acually introduce handlers which does datomic transactions not as a side effect.

@nidu ^

@drapanjanas: looks very cool, I will try it!

Is there something about Datomic that makes it particularly pleasant to use with pneumatic-tubes & re-frame? Maybe related to smart diffing that magically minimizes the amount of traffic (the way vdom minimizes repaints)?

@fasiha well I am not sure yet, but I try using datomic transaction queue to 'listen' to db changes and publish events to connected re-frame apps as a reaction on particular changes in db. This way events from client apps only responsible to change the DB and 'reaction' events are published back to clients when certain parts were changed. That is only an idea I will publish some example some time if it works out

That sounds really interesting: then, just like onClick or onChange are events that need re-frame handlers, certain db changes (via Datomic or Rethinkdb changefeeds) can also be thought of as events, with handlers that update local app-db over internet tubes.

I've also been trying to evaluate whether 3rd party solutions like Kinto could work: http://kinto.readthedocs.org/en/latest/overview.html

What's the best practice for subscribing to and changing a nested map in the main db atom, as form inputs are modified by the user? EG: (default-db {:form {:a "" :b "" :c ""}}) and then I have a form with 3 inputs, a b c, that should update the form map when those inputs are changed?

(I know it's simple, I'm just struggling to find the documentation for the "best-practice"... or is there a library I should be using to make forms?)