Documentation too limited

[nvwhaer]

I really think CQRS is an interesting way of implementing distributed systems.
However, I have been looking at the sample app for several hours now and the longer I look into it, the more questions it raises.

The documentation link refers to http://adrai.github.io/cqrs/pages/eventdenormalizer.html. But that ain't documentation. The usage samples are ok but what does every single module do? What's it's purpose? What's missing?

I started by shutting down the domain server. Messages where still accepted but surely not handled. The user gets no indication of this whatsoever. Is that considered acceptable or just left out? When left out, what would be needed to add it? What's the added value of the Redis PubSub server?

What if there is more than 1 aggregate? Would every browser (socket) get every message for every aggregate even when not interested or not even authorized? How to deal with that? What about the traffic load?

I am sure these cqrs modules would get used way more if the documentation was improved. I don't feel like inventing the wheel myself but I am also not able to make an estimation as to what it would take to use these modules. And that's a shame, especially because this package looks to be the most thought through one, of the ones available.

[adrai]

You're absolutely right... I don't really have documented these modules... sorry.
I simply had no time to document it.
But I can say, that these modules are used to help building distributed cqrs systems. They don't solve every aspect, but they give you a good start.
Personally I've already built a 2-3 larger systems with this modules and the help of (d)ddd = (distributed) domain driven design:
http://adrai.github.io/cqrs/pages/domain.html
http://adrai.github.io/node-eventstore/
http://adrai.github.io/cqrs/pages/eventdenormalizer.html
http://adrai.github.io/cqrs/pages/saga.html
http://adrai.github.io/cqrs/pages/viewmodel.html

But to give you some hints:
We usually build our cqrs clients so they just send a command and if there is no corresponding event that comes back or a commandRejected event in a certain amount of time the user gets informed, or it will retry... etc...

In this sample the redis pubsub server is just to remember to distribute everything (for example with a messaging service). We often use RabbitMQ.

To control that an event will only go to the correct client you need an authorization component that will filter the resulting events for the correlated user/session...
Hint for traffic load: Try always to transport "the intention" NOT the data. Do not transport blob files in the messages.

Generally: to learn more about cqrs and (d)ddd follow @udidahan @abdullin @ziobrando and a lot more ;-)