What does HackerNews think of commanded?

For anyone interested in event sourcing with the actor model I've built an open source Elixir library called Commanded (https://github.com/commanded/commanded) which takes advantage of Erlang's BEAM VM to host aggregate processes. There's also an event store implemented in Elixir which uses Postgres for storage (https://github.com/commanded/eventstore).

The actor model provides the guarantee that requests to a single instance are processed serially, while requests to different instances can be processed concurrently. Distributed Erlang allows these instances to be scaled out amongst a cluster of nodes with transparent routing of commands to the instance, regardless of which connected node it is running on.

In Elixir and Erlang, the OTP platform provides the building blocks to host an aggregate instance as a process (as a `GenServer`). Following the "functional core, imperative shell" style I model the domain code as pure functions with the host process taking care of any IO, such as reading and appending the aggregate's events.

A lot of finance is built on event sourcing (without calling it that), in that you can’t just overwrite your existing DB state with new state; everything has to be a ledger with a history, and you have to be able to trace the “provenance” of your data—what version of your business rules were used to compute any derived results, both so that those results (and results derived further from them) can be recomputed when you update your logic; and so you that you can use the version of the business rules appropriate to a given dataset (e.g. the tax laws appropriate for the year a given invoice was generated) when auditing that dataset, or when migrating that dataset to a new storage format.

Basically, you want:

• a runtime that forces a functional/immutable programming style (because it’s so much harder to avoid errors in algorithms that operate on mutable data), and which has lots of persistent data structures to make this style efficient;

• concurrency for processing unrelated batches;

• workload isolation (where one batch-job workload crashing doesn’t bring down your whole job processor);

• runtime inspectability and tracing (because it’s hard/illegal to replicate production customer data in staging to get matching conditions)

• a solid library to transit data between a DBMS and native record types (a Record-Relational Mapper lib), with fluent syntax for advanced relational querying features;

• and, of course, a solid Rails-like backend MVC framework to stick on top, to give people an API and web app view into your system†.

So, a lot of these companies are choosing an Elixir+Phoenix stack 85% because of ERTS, 10% because of Ecto, and 5% because of Phoenix itself.

For the companies that realize that what they’re doing is Event Sourcing, the https://github.com/commanded/commanded CQRS/ES framework is also an exciting “feature” of the Elixir ecosystem.

† Sometimes this is considered a separate need—you can build the business event-processing system, in Elixir, as a custom e.g. gRPC API service; and then you can use whatever you want for the web-API/web-app service that fronts it. Sometimes these shops use Rails for the web layer! But just as likely they use Node (because they delegate the front-end layer—now free of business logic—to the front-end devs, and front-end devs know JS) or Elixir+Phoenix (if the same backend devs writing the event-processing system are tasked with writing the web layer.)

Personally, I've heard of it in the context of https://github.com/commanded/commanded, a CQRS framework for Elixir that supports EventStore as a storage backend.

I think the idea is that it's something simpler than a database. It's more like an append-only file that has on-insert triggers/durable running queries. (Sort of like https://www.pipelinedb.com/ does, or like blockchain nodes do.)

Or, you could think of it as message queue like Kafka, with permanent durability of all "messages", and a single fixed subscriber bolted onto the queue server, where that subscriber is exposed through the queue server's API, allowing users to reprogram it arbitrarily.