Thanks Martin. On Tuesday, 6 May 2014 15:53:28 UTC+8, Martin Krasser wrote: > > > On 06.05.14 09:31, Ashley Aitken wrote: > > Reactive I take to mean push, the events are driving action in the system, > from GUI to GUI. > > From a user's (= API) perspective, a View will always receive Persistent > messages (regardless whether it is working internally with a pull or push > mechanism) i.e. a View always *reacts* to Persistent messages. It's this > perspective that counts. > I am confused though, about how the whole "eventual consistency" of CQRS > fits in with reactive systems, it seems like a sort of lazy reactivity, > i.e. we'll get around to reacting to the event sometime soon ;-) > > > Can you explain further why you think it doesn't fit? >
I guess you have a slightly weaker interpretation of reactive than mine. I feel reactive needs to be event-based and thus push. As an analogy, a Web application in which a user had to refresh the page to see any changes wouldn't be reactive (IMHO). That said, a regular enough pull can approximate a push. With regards to Akka Persistence this may mean the Views (or another read > model maintained by the Views) having some sort of open connection to the > client to forward on read model events (if there are such things?). > > > There are numerous implementation options to notify clients about events > occuring on server side. For these notification to work, there must be some > sort of connection between the client and the server. For example, > long-polling is one option for a web client to *react* to server-generated > events. I don't understand why you think this contradicts reactivity? > Sorry, if I was not clear. I see this as the way to reactivity, e.g. commands from the client may become domain events on the server that may result in changes to the read model that may produce view events that are transmitted to the client which requests any updated view data it needs. No polling. That would seem to me to be a necessary aspect of any CQRS implementation desiring a reactive client. Interestingly (to me at least ;-), the Meteor JS framework has "latency compensation" so that views in the client are updated immediately to reflect changes without waiting for the server but later if the server produces different results (e.g. denies the changes) the client's view is patched to show the true result. I guess that's for a limited type of applications though and the patching could be somewhat disconcerting for the user. Cheers, Ashley. -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
