On 06.05.14 09:31, Ashley Aitken wrote:
On Tuesday, 6 May 2014 15:18:29 UTC+8, Martin Krasser wrote:
The availability of (new) events in the journal is also an event.
Whether a view is actively notified about their availability (=
push) or if the view tries to find out itself (= pull) is rather a
technical detail. A pull-based view even allows to decouple a
processor from its view(s) in the dimension of lifetime. Why do
you see this in conflict with being reactive?
Reactive I take to mean push, the events are driving action in the
system, from GUI to GUI.
With the current way Views work I don't see them as supporting a
reactive system (not a criticism), but as you mentioned this is a
technical detail that may change in a later version of Akka Persistence.
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.
An upcoming feature in Akka will also allow the creation of reactive
stream producers from messages written by a processor, see also this
pull request <https://github.com/akka/akka/pull/15036>. The rate at
which the journal is polled for new messages depends on the downstream
consumers demand. Here again, it is a technical detail whether this
producer is internally polling for new messages or not.
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?
Of course, CQRS is proving to me that eventual consistency is fine for
most (if not nearly all) situations but I wouldn't call it reactive
(personally), and I would like to know what to do when we really need
reactivity.
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?
Thanks Martin.
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 akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
