Why replikativ?

Are you tired of building the same kind of glue code for your
distributed architecture over and over again? Then, once you have build
all this often redundant code coordinating state changes between
different ‘cloud’ systems, web services (e.g. RESTful) and your
client-side applications you try the impossible by bridging strongly
consistent storages with eventual consistent and volatile ones? Do you
think ad hoc solutions to cache invalidation are stupid? Do you wonder
whether there is a better way?


More information on our new project homepage :): http://replikativ.io/
To play around I recommend chat42: https://github.com/replikativ/chat42

The other projects should work, but are not updated yet. Please open an
issue if you fail with anything!



This release in particular offers:

- robustness. We have tested replikativ under serious load and ensured
that the frontend APIs developers face are safe to use concurrently with
our tests. We also have built-in the Erlang-like error handling of
superv.async to never miss an exception (hopefully ;) ).
- performance: We were able to follow Trump shitstorms on twitter over
more than a week including casual online synchronization onto a Laptop
with Datomic for analysis. This in particular included >200.000 commit
operations and more than 10 GiB managed data. There are still small
memory leaks, so you cannot run a peer in such a setting without
supervision for weeks yet, though.
- streaming: We now support stream-into-identity! functions for our
major datatypes: CDVCS, OR-Map and LWWR. In particular you can use them
to replicate data between different instances of databases like Datomic.
- more datatypes: We now have a very handy OR-Map, which also features
chat42, so you don't have to care about conflicts anymore with
distributed writers. The LWWR is also useful to have simple setable
(last writer wins) register.
- libraries: We have improved considerably on our kv-storage layer by
providing more backends and durable datastructures like an append-log
(trees WIP): https://github.com/replikativ/konserve
Our network library kabel has not seen as much love yet, and it probably
has a deadlock somewhere, as its tests get stuck sometimes, this needs
investigation.

I am keen on your feedback. If you miss anything or find something
unclear, please let us know!

Happy hacking,
Christian

P.S.: I will present the system at ClojureD.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to