Query in AKKA.NET

Question

I'm trying to understand the Query side of CQRS in a Catalog Management application built with AKKA.NET. I have a UI which needs to show all the products in a grid that follows a criteria. The criteria can be All Products that came from Vendor A and this criteria is entered on a form on the UI.

My question is how this query is being done? Where should I go to run the query? Should I load all the product actors to memory to do the query? Or should I go to the persistent media where the state is saved? After I get all the product ids that succeeded with the query, I should use those product ids to activate all the actors?

Please advise.

Answer 1

Your question doesn't sound like strictly actor related, since it's more CQRS vs. CRUD characteristic. In standard CQRS scenario you want to have some kind of persistent storage with schema adjusted to your read model. Then you can run your queries on it.

One of the things that comes to my mind using Akka.NET in CQRS-based but not yet event-sourcing scenario, is to utilize Akka event bus. When you start an application, create actors responsible for updating your read model and immediately subscribe them to Akka event bus for listening messages denoting, that read model must be updated. Then in any actor which may provoke read-side changes, publish a related event/message.

If you're using event sourcing, you would probably like to take a look at Akka.Peristence. There you have a concept of event journal created by so called persistent actors. It describes the stream of all operations made by an actor, which should have been stored. Second thing is another kind of actor called persistent view, which may be associated with particular stream of events and build read model from them. While persistent view is usually correlated with a single persistent actor, you may again use event bus + listeners to create a global read models. One of the advantages of this approach is that all events are stored in persistent storage, making your system more durable and easier to recover in case of failure.

Answer 2

Or you could flip your thinking on its head and create an Actor that represents a query. If you are querying the "Products" objects looking for all products from vendor A, then each Product object would send your query actor an update of its current state, if its from Vendor A your Query Actor processes the object adding it to its collection etc. Your query actor would filter out objects that don't fit with in the query parameters. Now you have an actor that contains a list of products that is getting updated in real time as new products are created, changed etc.