These are chat archives for RBMHTechnology/eventuate

12th
Jan 2016
Martin Krasser
@krasserm
Jan 12 2016 03:55
I started to read the book (and I really like it) but I just skimmed over the event sourcing chapter. I think it would be an interesting extension to Eventuate to additionally offer a pure functional programming model and use Eventuate's distributed/replicated event log as the underlying storage backend with all the ordering/consistency guarantees it provides. The current programming model of Eventuate is actor-based, providing different abstractions for implementing a CQRS/ES architecture in which actors can also collaborate via events. I don't see an issue that these two programming models can co-exist using the same underlying event log implementation. In another project, for example, I used Apache Camel and extended it with a pure functional programming model using scalaz-stream. A similar approach could add a pure functional programming model, as described in the book, to Eventuate. However, this is currently not a high priority. Hope that answers your questions.
Juan José Vázquez
@juanjovazquez
Jan 12 2016 08:34
Got it!. I'll have a look to Streamz which seems very interesting. Thanks.
Martin Krasser
@krasserm
Jan 12 2016 10:41
@juanjovazquez it has nothing to do with event sourcing though ...
Juan José Vázquez
@juanjovazquez
Jan 12 2016 15:07
@krasserm , yes I know, but it's interesting to see different approaches to the problem of making pure functional APIs on top of actor-based systems. In fact, my question about Debasish's book came up asking if it would be possible to apply a pure functional approach to CQRS and eventsourced distributed systems. Currently, my domain-driven microservices follow basically the architecture depicted in this activator template which is strongly based on Akka Persistence and Cluster Sharding. Of course, I'm also evaluating Eventuate as an alternative, but both are actor-based as you mentioned before. I was wondering if it would be feasible to expose a pure functional API on top of these actor-based frameworks or even if you've already evaluated this. If not, it would be great to know why did you consider it's better (or enough) to stick to the actor-based only implementation.