-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Decentralize/isomorphize API (+ P2P, etc) #13
Comments
Yes. We use There also needs to be something like |
In some recent work getting local first (true sync; optimistic update; offline write availability, etc) working on clients (see commits 0fc7139, 25c93e1 and 4c75956), we've realized that using centralized Datomic eids via
:dat.sync.remote.db/id
on the client is an absolute mess of state maintenance. Everything ends up being much simpler if we just assume there are:db.unique/identity
attributes we can use for asserting global identity between entities. As a bonus, this opens up the opportunity for us to use the same datom/tx translation mechanisms on the client and server, and thus eliminate the need for distinctions between client/server (everything is a remote, no matter where you are). This can potentially lead to a singledat.sync
namespace with generalized translation functions. It will, however, involve creating some abstractions for letting us seamlessly handle DataScript vs Datomic. These may end up being generally handy as part of the public API as well.Note that this connects with #12, as once we're fully utilizing lookup refs from identity attributes in our translations, there's no need to keep
:dat.sync.remote.db/id
any longer, and in fact, doing so makes it harder to get true P2P functionality.The text was updated successfully, but these errors were encountered: