-
Notifications
You must be signed in to change notification settings - Fork 18
The Vision
Stop right now and go do two things: Read the re-frame README, then watch the video the author keeps going on about (Turning the database inside out with apache samza).
From the re-frame README (discussing the qualification of describing re-frame as FRP-like in nature):
But, these days, FRP seems to have become a "big tent" (a broad church?). Broad enough perhaps that re-frame can be in the far, top, left paddock of the tent, via a series of qualifications: re-frame has "discrete, dynamic, asynchronous, push FRP-ish-nature" without "glitch free" guarantees. (Surprisingly, "glitch" has specific meaning in FRP).
This application architecture is based around these ideas.
It picks up where they left off and says:
- If we like servers and database architectures that look like one distributed persistent log structure being streamed into materialized views of the data (al a Samsa)
- And we like mimicking this in a FRP-ish "Reactive-Atom Component Event Subscription" (RACES, to quote re-frame again) framework on the front end (al a re-frame)
Then we like systems that look like this "all the way down"
In this paradigm of FRP that has emerged here (and elsewhere actually), there is the recurring theme of looking at a centralized state store on the client as a database. This way, everything in the UI is transactional, helping us reason about the system.
However, when we do this we sort of wave our hands and say "think of the atom as a db!" But an atom is sort of an ad-hoc db. It has (limited but sufficient) transaction semantics, but doesn't care about the data inside. In general, the data itself is just some typical Clojure data structure, like a tree of maps and vectors. While this is typically fine for starters, for anything but the most trivial of apps, we need to deal with the relationships between the different parts of our data structure. In other words, we end up wanting something a little more than an ad-hoc database.
DataScript commendably fills the gap.
It offers us a data structure with relational semantics, modeled closely after Datomic's entity/datom model (which is itself based on RDF), complete with datalog and pull queries.
DataScript's conn is really just an atom with some fancy metadata that lets us add transaction listeners.
While Re-frame gets around the mess of cursors and lenses with an event log and reactions, DataScript more directly gives us a queryable log of datoms (facts in time about entities). For the reactivity that Re-frame/Reagent's materialized-view/subscriptions/reactions give us, we look to Posh. There's still some work to do here in more efficiently maintaining these materialized views, but Posh throws us a bone by making sure that these queries aren't re-executed unless some new transacted datoms appear to match the query and parameters. Incremental view maintenance (in database speak) will make it possible to much more efficiently compute the new result given the former result.
The only question that stands then is: How do we handle traditional server data flow? For instance, if we want to save and retrieve data from a central server database, how should we fit that into our flow?
Re-frame leaves this a little up in the air. Certainly, it's clear that you plug the data in via the standard event handling system, but outside that you're on your own. As well you should be! I don't think it would be wise to bake in any particular assumptions about how you want to connect to the outside world as far as their concerned.
However, we're in a somewhat different situation. Assuming you're interested in using DataScript on clients, there's a decent chance you're interested in using DataScript or Datomic on the server. As such, wouldn't it be nice if there were some utilities for assisting with the transmission of datoms to and from server/client?
Enter Nikita Prokopov's The web after tomorrow. In this blog post, Nikita paints a stunning vision of a future of web development in which we can seamlessly sync DataScript and Datomic databases subject to authorization and scoping filters.
Datsync's goal is to fulfill this vision.