aecor

Pure functional event sourcing runtime (by notxcain)

Aecor Alternatives

Similar projects and alternatives to aecor based on common topics and language

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a better aecor alternative or higher similarity.

aecor reviews and mentions

Posts with mentions or reviews of aecor. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2021-12-06.
  • Endless4s: a new Scala library to describe event sourced entities using tagless-final algebras, running with built-in implementations for Akka
    2 projects | /r/scala | 6 Dec 2021
    Thanks, and thanks for your question! So regarding production use I wish I could tell you that we have load on a service using this, but as of just now it's not the case. It's recent and we're using this in a new micro-service which is not seeing much load yet. However this builds up on experience we've had dealing with Akka clusters for the past three years or so. We've been trying to find a way to have a lean and expressive domain while retaining Akka's power for a while, we actually published this article a while back where we were still using an OOP approach. Then we found out about a library, aecor, which was going full FP with the domain. However, we could not use the library directly for a number of reasons, chiefly because we are attached to keeping the layer above Akka as lightweight as possible and we want to keep a tight control on serialization aspects for rolling deployment. There also are other more differences: for instance we consider command rejections as first-order values, therefore opting for Either for replies. In endless, we’ve also tried to stick close to DDD & Akka nomenclature as much as possible. All in all I'm confident as it's lightweight and there is no magic, we simply delegate to Akka's DSL, we're not re-implementing an actor runtime. The main value in this approach IMO is the separation of concerns: it allows lean and expressive description of the domain, while retaining precise wire protocol handling in the infra layer. We also introduced some cool abstractions to manage side-effects and control passivation explicitly. The downside could be that tagless final isn't necessarily easy to bootstrap in a codebase when you're not used to it. But what I found it is that if someone with experience or time to experiment bootstraps the project, it's not so difficult to get the others on-board afterwards since the domain is easy to read and replicating the patterns isn't so difficult. Where it gets a bit fancy is with the usage of natural transformations internally, for which we rely on cats-tagless. That requires annotating traits involved in entity behavior with `@autofunctorK`. This also prevents us to go to scala 3 for now as `cats-tagless` is blocked on some missing macro feature . The project has a functional sample application that you can play with so that you can get a feel of how it looks in practice. If you do, make sure to let me know how it goes and if you have further questions!

Stats

Basic aecor repo stats
1
320
0.0
10 days ago

notxcain/aecor is an open source project licensed under MIT License which is an OSI approved license.

The primary programming language of aecor is Scala.

SaaSHub - Software Alternatives and Reviews
SaaSHub helps you find the best software and product alternatives
www.saashub.com