Not a "Can I?" but a "Should I"

I am new to EventstoreDB and CQRS. My original pattern was to be receive the command, append it to a stream, then publish a message on a message queue like RabbitMQ. After finding EventStoreDB, I think I see, I can have EventstoreDB do projections for me aggregating data etc.

So if for instance I made an app that was the tasks on a Kanban board, I could make a projection for the count of tasks in a particular state.

I was originally planning on subscribers to the message bus handling these types of use cases. What are the reasons I would want to use projections in stead?

I cannot imagine, that everything can be handled in a projection, and I also am a proponent of symmetry, to me this feels like I can, but I shouldn’t.


Could you not use both?
For your example, it sounds like projections would be ideal for keeping count.
The subscribers can simply listen to these projected values (as enriched events)

append it to a stream, then publish a message on a message queue like RabbitMQ.

you don’t need to publish to yet another queue.

  • you process the command directly , and eventually append it in a stream for audit/ log / some purpose
  • you append it to a stream & have worker processes subscribe to it and perform any required actions and append events to relevant ‘entity’ stream

to use projections in stead

I guess you mean the Javascript projections ?
if yes , the primary use case there is repartitioning of events into new streams (mostly via a linked events)

Sorry I am still learning the jargon, by projection I did mean the JavaScript ones, My question was that you could do a considerable number of use cases without a message bus and using the JavaScript projections, but I wasn’t sure if it was good practice to have a mixed bag.

I am an olde time MSSql programmer and you could write database triggers for things on insert update etc, but that almost always lead to some sort of problem in the long run. So it turned out you shouldn’t use triggers.

I was just asking if the JavaScript projections were going to lead me the same path.

Well contrary to database trigger the JS projection will not prevent / cause strange error,
they react to events that have been committed & can only append new information.
They own the streams they write to , so user code appending to it is not allowed).