Aecor Alternatives
Similar projects and alternatives to aecor based on common topics and language
-
-
akka-persistence-cassandra
A replicated Akka Persistence journal backed by Apache Cassandra
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
Clickhouse-scala-client
Clickhouse Scala Client with Reactive Streams support
-
endless
endless is a library to build distributed systems in functional Scala using a pluggable runtime model (by endless4s)
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
aecor reviews and mentions
-
Endless4s: a new Scala library to describe event sourced entities using tagless-final algebras, running with built-in implementations for Akka
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
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.