On Thu, May 8, 2014 at 10:28 PM, Akka Team <akka.offic...@gmail.com> wrote:
> Hi Ashley, > > it is good that you ask these questions! [answers inline] > > On Tue, May 6, 2014 at 8:28 AM, Ashley Aitken <amait...@gmail.com> wrote: > >> >> >> I thought reactive applications were all event-based and, in particular, >> events could be generated and flow through an application from GUI back to >> GUI. >> > > Yes, “reactive” means that all components react to change and disseminate > change in a way that focuses on the flow of information across the > application. This is crucial in achieving scalability and bounded latency > (i.e. responsiveness). > > >> >> Does the way Akka Persistence Views work prevent this (since they are, if >> I understand correctly, essentially polling for events)? >> > > Conceptually a View models how data flow from one persistent actor to > another actor, so on that level it is in accordance with Reactive > Principles. You are correct to point out that the need for polling in the > current journal and view implementations incurs latency overhead that is > sometimes unnecessary, but on the other hand it also allows the batch > processing of updates which makes the execution on today’s hardware more > efficient (see Smart Batching). It is a trade-off and as such there is no > generally “best” solution. We will certainly see improvements and > optimization work in this area, especially concerning the streaming of > events from truly reactive journals with Reactive Streams. But that > requires the journal implementation to support such a scheme in the first > place. > > >> >> Can a reactive path be constructed in another way with Akka Persistence >> that can be used in distributed applications? >> > > Instead of relying on Views you can of course send events as normal > messages from one actor to the next, which would achieve what you are > asking for. > > >> >> Are reactive applications compatible with the "eventual consistency" of >> CQRS? >> > > They are not merely compatible with it, the need for distribution that > arises from the Scalability and Resilience traits forces us to abandon > sequential consistency in favor of a weaker model that supports > distribution (see also CAP theorem and Pat Helland’s paper on “Life Beyond > Distributed Transactions”). CQRS is a data model that is geared towards > achieving high availability and sufficient consistency at both the write > and read sides of a system, and as such it very much supports the design of > reactive applications. In fact I do not currently know another model which > comes as close to the ideal as CQRS/ES (which benefits greatly from DDD). > Totally agree. It is essential. It also supports sharding at any level of granularity and a true pay-for-what-you need model. To illustrate the point: for full consistency, use a single transaction log (which is what Datomic does with its Transactor), or for a more scalable (but more complicated) design shard your application in smaller chunks for better scalability—fully consistent within each shard but eventually consistent between. The hard part is not the tech but changing the way you look at the world and design systems. Pat Helland's paper is a must-read. > > >> >> Please excuse my ignorance if this question doesn't make sense and I am >> not criticising anything, just trying to understand. >> > > Your questions do make a lot of sense and I hope I could help you with my > answers. > > Regards, > > Roland > > >> >> Thanks, >> 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 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. >> > > > > -- > Akka Team > Typesafe - The software stack for applications that scale > Blog: letitcrash.com > Twitter: @akkateam > > -- > >>>>>>>>>> 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. > -- *Jonas Bonér*Phone: +46 733 777 123 Home: jonasboner.com Twitter: @jboner <https://twitter.com/jboner> -- >>>>>>>>>> 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.
