On 06.05.14 19:10, Ashley Aitken wrote:
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.
No, we have the same understanding that reactive means event-based and
thus push. Of course, requiring a user to manually refresh a web page is
*not* reactive. Long polling (mentioned below) is just a technology to
*emulate* a server push to clients over HTTP (see also Comet
<http://en.wikipedia.org/wiki/Comet_%28programming%29>, but I'm pretty
sure you're familiar with that). Although (long) polling is used under
the hood, the user experience is that events are pushed to the client.
Similar arguments apply to pull/push when using views (although the
underlying technology is different). Hope that clarifies things.
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.
As explained above. Push from a user's perspective and a Comet
<http://en.wikipedia.org/wiki/Comet_%28programming%29> (or web socket or
whatever ...) under the hood to push these changes to the web client (no
*explicit* polling/refresh by the user).
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.
--
Martin Krasser
blog: http://krasserm.blogspot.com
code: http://github.com/krasserm
twitter: http://twitter.com/mrt1nz
--
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.
