Best Reactive Programming Books

Usually the first problems you solve with the new paradigm are the ones that were unsolvable with the old paradigm 🚂
~ Joel A. Barker (Paradigm Shift)

This book is so reactive, it belongs on the left-hand side of the periodic table!
~ Andy Hicks (reviewing Reactive Design Patterns by Kuhn, Hanafee, and Allen)

Let It Crash: In the endearingly memorable words of a coding philosophy 🚂
~ Joe Armstrong

Stand in the place where you live 
Think about direction 
Wonder why you haven’t before 

If you are confused, check with the sun
Carry a compass to help you along
Your feet are going to be on the ground
Your head is there to move you around 🔭
~ R.E.M (lyrics from Stand)

The Illustration above is from The Reactive Manifesto

The reactive programming paradigm has swept deep through the landscape of our industry, transforming—and continuing to transform—it for the better. This paradigm shift is, IMHO, right up there with when object-oriented programming appeared on the scene, back in the eighties. Functional programming, of course, continued to make steady progress, all the while, making increasingly wider and deeper forays into the thicket of the programming industry, cutting through swathes of complexity, gaining mindshare, and becoming mainstream in the past few years. And here we are, witnessing the blossoming of another paradigm, as reactive programming paradigm has shifted our mindset by going mainstream.

Come writers and critics
Who prophesize with your pen
And keep your eyes wide
The chance won’t come again
And don’t speak too soon
For the wheel’s still in spin
And there’s no tellin’ who that it’s namin’
For the loser now will be later to win
For the times they are a-changin’
~ Bob Dylan (lyrics from The Times They Are A-Changin’)

The confluence of functional programming, steeped as it is in the queen of the sciences, mathematics—and math doesn’t get stale—of OOP, of hard-won concurrency best practices gleaned from the trenches, of the actor model, of the industry-reenergizing Akka project, as well as a host of other factors, has revitalized our industry: In the words of The Reactive Manifesto:

We believe that a coherent approach to systems architecture is needed, and we believe that all necessary aspects are already recognised individually: we want systems that are Responsive, Resilient, Elastic and Message Driven. We call these Reactive Systems.

To help guide newcomers through the landscape of the reactive programming paradigm, I share, in this essay, my take on the very best (book-format) resources available. My hope in doing so—and I have spent serious time grappling with the material in each book—is that you, too, will be equipped thereby to design systems that are Responsive, Resilient, Elastic and Message Driven.

Without further ado, here, then, is my list of  the very best (book-format) resources that I have found, yet:
  1. Reactive Design Patterns by Roland Kuhn, Brian Hanafee, and Jamie Allen (Manning Publications) 💰
  2. Functional and Reactive Domain Modeling by Debasish Ghosh. (Manning Publications) ⛰
  3. Reactive Messaging Patterns with the Actor Model: Applications and Integration in Scala and Akka by Vaughn Vernon (Addison-Wesley Professional) 🚅
  4. Reactive Web Applications: With Play, Akka, and Reactive Streams by Manuel Bernhardt (Manning Publications) 📶
  5. Functional Reactive Programming by Stephen Blackheath and Anthony Jones (Manning Publications) 🔌
Allow me, though, to first ask: Is your favorite reactive programming book(s) missing from this list? If so, please post your comments on this blog so I can include your book(s) in the sequel of this review; I’ve reviewed only a subset of the burgeoning number of fine books that have been written—and continue to be written—on this intriguing subject.

    I hasten to add that online resources remain indispensable and fantastic in their own right, especially for keeping up with leading edge updates. But what about times when you simply want to sit down and really absorb the wisdom of our reactive design sages—the underlying conceptual constructs that power the design of next generation software—in a more sustained and methodical way? And that is where the resources, which I review in this essay, come in.

    Before moving on to the reviews themselves, I wish to underscore that my liberal references to mathematics are not random; as a computer scientist, I have deep and abiding respect for the power of mathematical thinking. Consider that Turing himself was a mathematician, of the highest order. That brings me to the symbiosis, as it were, of functional programming (FP) and object-oriented programming (OOP). And FP is firmly grounded in mathematics, giving us new—or, more precisely, newly-gone-mainstream—ways of reasoning about software design and code.

    This is a whole subject in itself, but I invite you to hold on to the thought, on this theme, that Martin Odersky—creator of the Scala programming language—has nicely articulated when noting in the Foreword to the sparkling book Functional Programming in Scala (Manning Publications) by Chiusano and Bjarnason that:

    In fact, it’s quite possible to write Scala as if it were Java without the semicolons… So to properly learn functional programming in Scala, should one make a detour via a pure functional language such as Haskell? Any argument in favor of this approach has been severely weakened by the appearance of Functional Programming in Scala. What Paul and Rúnar do, put simply, is treat Scala as a pure functional programming language. Mutable variables, exceptions, classical input/output, and all other traces of impurity are eliminated. If you wonder how one can write useful programs without any of these conveniences, you need to read the book. Building up from first principles and extending all the way to incremental input and output, they demonstrate that, indeed, one can express every concept using only pure functions. And they show that it is not only possible, but that it also leads to beautiful code and deep insights into the nature of computation (emphasis is mine)

    With that, I submit to you these reviews…

      1. Reactive Design Patterns by Roland Kuhn, Brian Hanafee, and Jamie Allen (Manning Publications) 💰

      If you’re looking for the best-written, most-comprehensive treatment of reactive design, look no further than Reactive Design Patterns by Roland Kuhn, Brian Hanafee, and Jamie Allen (Manning Publications). The contents of this book are overwhelming—in a good way—as there is so much that is of such high quality: the caliber of writing, the sparkling-clear illustrations, and the stellar code snippets. I cannot think of a better book from which to learn the reactive programming landscape than this amazing volume.

      It’s no wonder, then, that Jonas Boner, the driving force behind the reactive programming movement—now a full-fledged community of its own—is so pleased by the publication of this book, earlier this year (2017). In his Foreword to Reactive Design Patterns, Jonas acknowledges:

      I’m grateful that Roland has taken the time to write this foundational book, and I can’t think of anyone more capable of pulling it off. Roland is an unusually clear and deep thinker; he coauthored the Reactive Manifesto, has been the technical lead for the Akka project for several years, has coauthored and taught the very popular Coursera course on Reactive programming and design, and is the best technical writer I have met. 

      It outlines what Reactive architecture/design is all about, and does an excellent job explaining it from first principles in a practical context. Additionally, it is a catalog of patterns that explains the bigger picture, how to think about system design, and how it is all connected—much like what Martin Fowler’s Patterns of Enterprise Application Architecture did 15 years ago. 

      By now, the Reactive principles have had a big impact on the industry, and as with many successful ideas, they get overloaded and reinterpreted. This is not a bad thing; ideas need to evolve to stay relevant. However, this can also cause confusion and lead to dilution of the original intent. One example is the unfortunate emerging misconception that Reactive is nothing but programming in an asynchronous and nonblocking style using callbacks or stream-oriented combinators—techniques that are aptly classified as Reactive Programming. Concentrating on this aspect alone means missing out on many of the benefits of the Reactive principles. It is the contribution of this book to take a much larger perspective—a systems view—moving the focus from how individual components function in isolation to the design of collaborative, resilient, and elastic systems: Reactive systems. 

      This future classic belongs on the shelf of every professional programmer, right next to the GoF book (Design Patterns: Elements of Reusable Object-Oriented Software by Gamma, Helm, Johnson, and Vlissides) and Domain-Driven Design by Eric Evans. Enjoy the ride—I certainly did!

      Remaining mindful of my earlier remark about just how comprehensive this fine book is in its treatment of the exciting field of reactive design, I present here the table of contents to give you a flavor of the breadth (and depth) of the topics covered:

      1. Introduction 

      Chapter 1. Why Reactive?
      Chapter 2. A walk-through of the Reactive Manifesto
      Chapter 3. Tools of the trade 

      2. The philosophy in a nutshell 

      Chapter 4. Message passing
      Chapter 5. Location transparency
      Chapter 6. Divide and conquer
      Chapter 7. Principled failure handling
      Chapter 8. Delimited consistency
      Chapter 9. Nondeterminism by need
      Chapter 10. Message flow 

      3. Patterns 

      Chapter 11. Testing reactive applications
      Chapter 12. Fault tolerance and recovery patterns
      Chapter 13. Replication patterns
      Chapter 14. Resource-management patterns
      Chapter 15. Message flow patterns
      Chapter 16. Flow control patterns
      Chapter 17. State management and persistence patterns
      Appendix A. Diagramming Reactive systems
      Appendix B. An illustrated example
      Appendix C. The Reactive Manifesto  


      Among my favorite sections includes the one on compartmentalization and bulk-heading. I first became aware of these crucial design strategies from another fine book entitled Release It! Design and Deploy Production-Ready Software by Michael T. Nygard in which the author gently educated us, beginning with these sobering advice: “Feature complete” is not the same as “production ready.”

      Two standout chapters that especially resonated with me—and IMHO are not-to-be-missed—which I want to bring to your attention are these, along with the titles of sub-sections, to better give you a flavor of the coverage:

      Chapter 9. Nondeterminism by need
      9.1. Logic programming and declarative data flow
      9.2. Functional reactive programming
      9.3. Sharing nothing simplifies concurrency
      9.4. Shared-state concurrency
      9.5. So, what should we do?
      9.6. Summary 

      Chapter 17. State management and persistence patterns
      17.1. The Domain Object pattern
      17.1.1. The problem setting
      17.1.2. Applying the pattern
      17.1.3. The pattern, revisited
      17.2. The Sharding pattern
      17.2.1. The problem setting
      17.2.2. Applying the pattern
      17.2.3. The pattern, revisited
      17.2.4. Important caveat
      17.3. The Event-Sourcing pattern
      17.3.1. The problem setting
      17.3.2. Applying the pattern
      17.3.3. The pattern, revisited
      17.3.4. Applicability
      17.4. The Event Stream pattern
      17.4.1. The problem setting
      17.4.2. Applying the pattern
      17.4.3. The pattern, revisited
      17.4.4. Applicability
      17.5. Summary

      Here is a link to the book’s accompanying code, available freely on Github.

      In sum, Reactive Design Patterns provides sparkling clear insights into the value proposition that reactive design brings to the proverbial programming table 😎 Take a deep breath, and start reading. The contents of this book are overwhelming—in a good way—so much that is of such high quality: the caliber of writing, the sparkling-clear illustrations, the stellar code snippets

      2. Functional and Reactive Domain Modeling by Debasish Ghosh. (Manning Publications) ⛰

      Allow me to introduce a book that is almost lyrical in the beauty and elegance with which it tackles an incredibly tough subject, actually three whole subjects, to be precise: Functional and Reactive Domain Modeling by Debasish Ghosh. What the author has accomplished with this stellar book is not for the faint of heart: It takes three strands—functional programming, reactive programming, and domain modeling—and manages to weave them into a tapestry of awesome.

      Did I actually say that (lyricism, beauty, elegance, and all)? Well, I guess people have been known to grow lyrical when gripped by a narrative that is told with such uncommon insight and perspicuity that it leaves them with a heady feeling 😆 I am, though, reassured that I’m in good company as I recall what the mathematician and philosopher Bertrand Russel had to say on these very elementslyricism, beauty, elegance, and all:

      Mathematics, rightly viewed, possesses not only truth, but supreme beauty—a beauty cold and austere, like that of sculpture, without appeal to any part of our weaker nature, without the gorgeous trappings of painting or music, yet sublimely pure, and capable of a stern perfection such as only the greatest art can show. The true spirit of delight, the exaltation, the sense of being more than Man, which is the touchstone of the highest excellence, is to be found in mathematics as surely as poetry.

      What I appreciated the most about this book is the thorough and pragmatic approach taken by Debasish to weave three topics—each broad (and deep) in their own right—into a coherent narrative, copiously illustrated by high-quality code that you can load into your IDE (I used IntelliJ IDEA) and run.

      Jonas Boner (Founder of the Akka Project) articulates this point really nicely in his Foreword to Functional and Reactive Domain Modeling in noting that

      What captured me about this book is that it sets out on the rather bold mission of bringing together these three very different tools—domain-driven design, functional programming, and reactive principles—in a practical way. It teaches you how things like bounded contexts, domain events, functions, monads, applicatives, futures, actors, streaming, and CQRS can help keep complexity under control. 

      The magnificence of this book is nothing short of amazing. for any fellow programmer who has bludgeoned their head over how much math they need—specifically, category theory—to really grok how to use these mathematical concepts of category theory in their daily programming—and apply salve to your hurting head—this book is a balm 😅

      I hasten to add that Functional and Reactive Domain Modeling will challenge you: It’s an incredibly idea-dense volume—yes, in an eminently mathematical and SNR kind of way—reminding me in many ways of the seminal GoF book that started quite the revolution in our industry when it was published in 1995. Here is Jonas again, gently reminding the reader in his Foreword to Functional and Reactive Domain Modeling that:

      This is not a book for the faint of heart. It is demanding. But if you put in the hours, you will be rewarded in spades. Fortunately for you, dear reader, you’ve already taken the first step. All you have to do now is keep on reading.

      To give you a more visceral sense of the richness and depth of the topics covered, what follows is from the book’s TOC:

      Chapter 1. Functional domain modeling: an introduction
      1.1. What is a domain model? 1.2. Introducing domain-driven design 1.2.1. The bounded context 1.2.2. The domain model elements 1.2.3. Lifecycle of a domain object 1.2.4. The ubiquitous language 1.3. Thinking functionally 1.3.1. Ah, the joys of purity 1.3.2. Pure functions compose 1.4. Managing side effects 1.5. Virtues of pure model elements 1.6. Reactive domain models 1.6.1. The 3+1 view of the reactive model 1.6.2. Debunking the “My model can’t fail” myth 1.6.3. Being elastic and message driven 1.7. Event-driven programming 1.7.1. Events and commands 1.7.2. Domain events 1.8. Functional meets reactive 1.9. Summary 

      Chapter 2. Scala for functional domain models
      2.1. Why Scala? 2.2. Static types and rich domain models 2.3. Pure functions for domain behavior 2.3.1. Purity of abstractions, revisited 2.3.2. Other benefits of being referentially transparent 2.4. Algebraic data types and immutability 2.4.1. Basics: sum type and product type 2.4.2. ADTs structure data in the model 2.4.3. ADTs and pattern matching 2.4.4. ADTs encourage immutability 2.5. Functional in the small, OO in the large 2.5.1. Modules in Scala 2.6. Making models reactive with Scala 2.6.1. Managing effects 2.6.2. Managing failures 2.6.3. Managing latency 2.7. Summary 

      Chapter 3. Designing functional domain models The algebra of API design 3.1.1. Why an algebraic approach? 3.2. Defining an algebra for a domain service 3.2.1. Abstracting over evaluation 3.2.2. Composing abstractions 3.2.3. The final algebra of types 3.2.4. Laws of the algebra 3.2.5. The interpreter for the algebra 3.3. Patterns in the lifecycle of a domain model 3.3.1. Factories—where objects come from 3.3.2. The smart constructor idiom 3.3.3. Get smarter with more expressive types 3.3.4. Aggregates with algebraic data types 3.3.5. Updating aggregates functionally with lenses 3.3.6. Repositories and the timeless art of decoupling 3.3.7. Using lifecycle patterns effectively—the major takeaways 3.4. Summary

      Chapter 4. Functional patterns for domain models
      4.1. Patterns—the confluence of algebra, functions, and types 4.1.1. Mining patterns in a domain model 4.1.2. Using functional patterns to make domain models parametric 4.2. Basic patterns of computation in typed functional programming 4.2.1. Functors—the pattern to build on 4.2.2. The Applicative Functor pattern 4.2.3. Monadic effects—a variant on the applicative pattern 4.3. How patterns shape your domain model 4.4. Evolution of an API with algebra, types, and patterns 4.4.1. The algebra—first draft 4.4.2. Refining the algebra 4.4.3. Final composition—follow the types 4.5. Tighten up domain invariants with patterns and types 4.5.1. A model for loan processing 4.5.2. Making illegal states unrepresentable 4.6. Summary

      Chapter 5. Modularization of domain models

      5.1. Modularizing your domain model 5.2. Modular domain models—a case study 5.2.1. Anatomy of a module 5.2.2. Composition of modules 5.2.3. Physical organization of modules 5.2.4. Modularity encourages compositionality 5.2.5. Modularity in domain models—the major takeaways 5.3. Type class pattern—modularizing polymorphic behaviors 5.4. Aggregate modules at bounded context 5.4.1. Modules and bounded context 5.4.2. Communication between bounded contexts 5.5. Another pattern for modularization—free monads 5.5.1. The account repository 5.5.2. Making it free 5.5.3. Account repository—monads for free 5.5.4. Interpreters for free monads 5.5.5. Free monads—the takeaways 5.6. Summary

      Chapter 6. Being reactive
      6.1. Reactive domain models 6.2. Nonblocking API design with futures 6.2.1. Asynchrony as a stackable effect 6.2.2. Monad transformer-based implementation 6.2.3. Reducing latency with parallel fetch—a reactive pattern 6.2.4. Using scalaz.concurrent.Task as the reactive construct 6.3. Explicit asynchronous messaging 6.4. The stream model 6.4.1. A sample use case 6.4.2. A graph as a domain pipeline 6.4.3. Back-pressure handling 6.5. The actor model 6.5.1. Domain models and actors 6.6. Summary 

      Chapter 7. Modeling with reactive streams
      7.1. The reactive streams model 7.2. When to use the stream model 7.3. The domain use case 7.4. Stream-based domain interaction 7.5. Implementation: front office 7.6. Implementation: back office 7.7. Major takeaways from the stream model 7.8. Making models resilient 7.8.1. Supervision with Akka Streams 7.8.2. Clustering for redundancy 7.8.3. Persistence of data 7.9. Stream-based domain models and the reactive principles 7.10. Summary

      Chapter 8. Reactive persistence and event sourcing
      8.1. Persistence of domain models 8.2. Separation of concerns 8.2.1. The read and write models of persistence 8.2.2. Command Query Responsibility Segregation 8.3. Event sourcing (events as the ground truth) 8.3.1. Commands and events in an event-sourced domain model 8.3.2. Implementing CQRS and event sourcing 8.4. Implementing an event-sourced domain model (functionally) 8.4.1. Events as first-class entities 8.4.2. Commands as free monads over events 8.4.3. Interpreters—hideouts for all the interesting stuff 8.4.4. Projections—the read side model 8.4.5. The event store 8.4.6. Distributed CQRS—a short note 8.4.7. Summary of the implementation 8.5. Other models of persistence 8.5.1. Mapping aggregates as ADTs to the relational tables 8.5.2. Manipulating data (functionally) 8.5.3. Reactive fetch that pipelines to Akka Streams 8.6. Summary 

      Chapter 9. Testing your domain model
      9.1. Testing your domain model 9.2. Designing testable domain models 9.2.1. Decoupling side effects 9.2.2. Providing custom interpreters for domain algebra 9.2.3. Implementing parametricity and testing 9.3. xUnit-based testing 9.4. Revisiting the algebra of your model 9.5. Property-based testing 9.5.1. Modeling properties 9.5.2. Verifying properties from our domain model 9.5.3. Data generators 9.5.4. Better than xUnit-based testing? 9.6. Summary

      Chapter 10. Summary—core thoughts and principles
      10.1. Looking back 10.2. Rehashing core principles for functional domain modeling 10.2.1. Think in expressions 10.2.2. Abstract early, evaluate late 10.2.3. Use the least powerful abstraction that fits 10.2.4. Publish what to do, hide how to do within combinators 10.2.5. Decouple algebra from the implementation 10.2.6. Isolate bounded contexts 10.2.7. Prefer futures to actors 10.3. Looking forward 


      Here is a link to the book’s accompanying code, available freely on Github. So if you are a fellow programmer who has bludgeoned their head through repeated, and dare I say, valiant attempts at grokking category theory, then you owe it to yourself to check out this splendid book.

      Debasish is a prolific blogger, and I’ve followed his work, going all the way back to his fine volume on Domain Specific Languages (DSLs)—little languages, implemented atop conventional programming languages—and he has been graciously making us developers become more comfortable with the underlying conceptual (mathematical) machinery. I can think offhand to a fine post by Debasish: Does Category Theory make you a Better Programmer?

      Don’t miss this book. It’s like the GEB (Gödel, Escher, Bach: An Eternal Golden Braid) of programming in richness of content!

      3. Reactive Messaging Patterns with the Actor Model: Applications and Integration in Scala and Akka by Vaughn Vernon (Addison-Wesley Professional) 🚅

      Let’s now segue a bit into the crucially-important topic of the actor model, which of course is essential to making reactive systems tick responsively to ever-burgeoning user demands. Understanding the actor model deeply will serve you well in grokking the art of designing reactive systems, and you’ll find in this book—Vaughn Vernon. Reactive Messaging Patterns with the Actor Model: Applications and Integration in Scala and Akka (Addison-Wesley Professional)—a terrific and gentle guide. This book is the paragon of sparkling clear prose and unambiguous explanations of all things actor model, especially as they are related to making reactive systems evolve into their finest. As a tech type, this is the kind of stuff I crave for 👍

      To appreciate the value proposition of this book, I invite you to spend some time poring over its Foreword. Here’s Jonas Boner again, this time articulating how this superb book will help you navigate the terrain of reactive programming. In particular, look for the pointer on how you are in store to find—in the pages of this volume—guidance on bridging the sometimes-perplexing chasm between actors and traditional enterprise messaging, by seeing actors in the context of building reactive systems:

      When Carl Hewitt invented the Actor model in the early 1970s he was way ahead of his time. Through the idea of actors he defined a computational model embracing nondeterminism (assuming all communication being asynchronous), which enabled concurrency and, together with the concept of stable addresses to stateful isolated processes, allowed actors to be decoupled in both time and space, supporting distribution and mobility. Today the world has caught up with Hewitt’s visionary thinking; multicore processors, cloud computing, mobile devices, and the Internet of Things are the norm. This has fundamentally changed our industry, and the need for a solid foundation to model concurrent and distributed processes is greater than ever…

      I’m really excited about Vaughn’s book. It provides a much-needed bridge between actors and traditional enterprise messaging and puts actors into the context of building reactive systems. I like its approach of relying only on the fundamentals in Akka—the Actor model and not its high-level libraries—as the foundation for explaining and implementing high-level messaging and communication patterns. It is fun to see how the Actor model can, even though it is a low-level computation model, be used to implement powerful and rich messaging patterns in a simple and straightforward manner. Once you understand the basic ideas, you can bring in more high-level tools and techniques…

      This book also does a great job of formalizing and naming many of the patterns that users in the Akka community have had to discover and reinvent themselves over the years. I remember enjoying reading and learning from the classic Enterprise Integration Patterns [EIP] by Hohpe and Woolf a few years ago, and I’m glad that Vaughn builds upon and reuses its pattern catalog, putting it in a fresh context. But I believe that the most important contribution of this book is that it does not stop there but takes the time to define and introduce a unique pattern language for actor messaging, giving us a vocabulary for how to think about, discuss, and communicate the patterns and ideas.

      In further amplifying and elaborating this theme, the author himself (Vaughn Vernon) notes in the Preface to Reactive Messaging Patterns with the Actor Model: Applications and Integration in Scala and Akka that:

      Today, many software projects fail… At the same time, some notable successes can be found among companies that use Scala and Akka to push the limits of performance and scalability. So, there is not only success but success in the face of extreme nonfunctional requirements. Certainly it was not Scala and Akka alone that made these endeavors successful, but at the same time it would be difficult to deny that Scala and Akka played a significant role in those successes. I am also confident that those who make use of these tools would stand by their platform decisions as ones that were key to their successes. 

      My goal with this book is to make you familiar with the Actor model and how it works with Scala and Akka. Further, I believe that many enterprise architects and developers have been educated by the work of Gregor Hohpe and Bobby Woolf. In their book, Enterprise Integration Patterns, they provide a catalog of some 65 integration patterns that have helped countless teams to successfully integrate disparate systems in the enterprise. I think that leveraging those patterns using the Actor model will give architects and developers the means to tread on familiar turf, besides that the patterns are highly applicable in this space.

      To boot, there is good humor sprinkled across its pages, pixie dust fashion 💥 I was ROTFL when I came across this jolly—embedded in the excerpt below—during my very first reading of this fine book:

      As a parting caveat, I suggest you stay away from the complex libraries, such as scalaz, at least in the beginning. You won’t need to solve problems with libraries meant to satisfy a specific programming style. So, if Functor and Monad sound like viruses you caught as a child, steer clear of scalaz for a while. You will still be productive with the Scala language features you will review in this chapter and throughout the book. After you are grounded in common Scala, it would make sense to venture into scalaz and the “pure functional data structures” it offers, as well as other advanced libraries and language features.

      I hasten to add that Scalaz is an awesome Scala library for functional programming. It is billed—very accurately, and modestly, so, if I may add—as providing ...purely functional data structures to complement those from the Scala standard library. It defines a set of foundational type classes (e.g. Functor, Monad) and corresponding instances for a large number of data structures.

      I also appreciated the book’s nice refresher entitled A Condensed Scala Tutorial. Another stand out quality of the Reactive Messaging Patterns with the Actor Model: Applications and Integration in Scala and Akka is the marvelously cross-referenced digital edition. Seldom have I seen cross-referencing done by a publisher to such great effect! (The only other book that approaches this lavish navigational finesse has got to be Programming in Scala: A comprehensive step-by-step guide, Third Edition (Artima Press)  by Martin Odersky, Lex Spoon, and Bill Venners.

      To better situate in your mind the high quality of the annotated and well-explained code snippets in the book, I submit here merely one example; this one happens to be the Return Address design pattern—one of the 65 EIP patterns with which Gregor Hohpe and Bobby Woolf enlightened us—in their the inimitable tome, eponymously titled Enterprise Integration Patterns. Thus, in elaborating on the pragmatics of the Return Address design pattern, the author (Vaughn Vernon) notes that

      When reasoning on Request-Reply (209), what if you want your request receiver to reply to an actor at an address other than the direct message sender? Well, that’s the idea behind Return Address, as shown in Figure 6.5, and one that you can implement in a few different ways. 

      That works, but it does require you to design the message protocol in a certain way. What if you have an existing message protocol and you later decide to redesign the existing receiving actor to delegate some message handling to one of its child actors? This might be the case if there is some complex processing to do for certain messages and you don’t want to heap too much responsibility on your original actor, for example the server. It would be nice if the server could create a child worker to handle a specific kind of complex message but design the worker to reply to the original client sender, not to the parent server. That would free the parent server to simply delegate to the child worker and allow the worker to react as if the server had done the work itself.

      Finally, here’s the TOC to get a flavor of the topics in the book:

      Chapter 1 Discovering the Actor Model and the Enterprise, All Over Again
      Why Enterprise Software Development Is Hard
      Introducing Reactive Applications
        Message Driven
      Enterprise Applications
      Actor Model
        Origin of Actors
        Understanding Actors
      The Actor Way Is Explicit
      What Next? 

      Chapter 2 The Actor Model with Scala and Akka
      How to Get Scala and Akka
        Using Typesafe Activator
        Using sbt
        Using Maven
        Using Gradle
      Programming with Scala
        A Condensed Scala Tutorial
      Programming with Akka
      Actor System
      Testing Actors
      The CompletableApp

      Chapter 3 Performance Bent
      Transistors Matter
      Clock Speed Matters
      Cores and Cache Matter
      Scale Matters
      Multithreading Is Hard
      How the Actor Model Helps
      Dealing with False Sharing
      The Patterns 

      Chapter 4 Messaging with Actors
      Message Channel
      Pipes and Filters
      Message Router
      Message Translator
      Message Endpoint

      Chapter 5 Messaging Channels
      Point-to-Point Channel
      Publish-Subscribe Channel
        Local Event Stream
        Distributed Publish-Subscribe
      Datatype Channel
      Invalid Message Channel
      Dead Letter Channel
      Guaranteed Delivery Channel
      Adapter Message Bridge
      Message Bus

      Chapter 6 Message Construction
      Command Message
      Document Message
        Managing Flow and Process
      Event Message
      Return Address
      Correlation Identifier
      Message Sequence
      Message Expiration
      Format Indicator

      Chapter 7 Message Routing
      Content-Based Router
      Message Filter
      Dynamic Router
      Recipient List
      Composed Message Processor
      Routing Slip
      Process Manager
      Message Broker

      Chapter 8 Message Transformation
      Envelope Wrapper
      Content Enricher
        Immutable DoctorVisitCompleted
        Should the AccountingEnricherDispatcher Be Local?
      Content Filter
      Claim Check
        Canonical Message Model
      Actor Systems Require a Canon

      Chapter 9 Message Endpoints
      Messaging Gateway
      Messaging Mapper
      Transactional Client/ Actor
        Transactional Client
        Transactional Actor
      Polling Consumer
        Resource Polling
      Event-Driven Consumer
      Competing Consumers
      Message Dispatcher
      Selective Consumer
      Durable Subscriber
      Idempotent Receiver
        Message De-duplication
        Design Messages with Identical Impact
        State Transition Renders Duplicates Harmless
      Service Activator

      Chapter 10 System Management and Infrastructure
      Control Bus
      Wire Tap
      Message Metadata/ History
      Message Journal/ Store
      Smart Proxy
      Test Message
      Channel Purger

      Appendix A Dotsero: An Akka-like Toolkit for .NET
      Dotsero Actor System
      Actors Using C# and .NET
      Dotsero Implementation



      Here is a link to the book’s accompanying code, available freely on Github. Using IntelliJ IDEA, I loaded and ran the examples without the slightest hitch—Good stuff 😂

      4. Reactive Web Applications: With Play, Akka, and Reactive Streams by Manuel Bernhardt (Manning Publications) 📶

      This next title is an excellent, no frills introduction to building reactive web applications with Play and Akka. It is entitled Reactive Web Applications: With Play, Akka, and Reactive Streams by Manuel Bernhardt (Manning Publications). The book’s unerring focus on practicality—all the while highlighting best practices—is very pleasing and helpful. One reviewer (Antonio Magnaghi, PhD, OpenMail) has correctly pointed out this book is

      A complete and exhaustive source of best practices for large-scale, real-world reactive platforms.

      I heartily agree with this assessment. When reading books, we’re all gotten used to doing the inevitable google searches periodically—to compensate for the equally inevitable gaps in the narratives of any given technology book—but this book is mercifully free of the aforesaid read-some, search-online-some, resume-reading syndrome, yay!
      Check out these observations in the Foreword to the book by James Roper, who is the lead developer of the Play framework:

      Until four years ago, every major web application that I had written used the tried-and-trusted thread-per-request execution model… At that time in our industry’s history, the word “reactive” was virtually unheard-of. 

      The switch to reactive applications has been the biggest architectural change since the web itself, and it has swept across our industry at lightning speed. What I considered far-fetched four years ago, I now use every day, and I am lead developer of Play, a framework that embraces it. With the concept evolving from relative obscurity to mainstream best practice in such a short time, it’s no wonder that countless web developers are asking the question, “What is reactive?” This is where Reactive Web Applications perfectly fills a gap. 

      I’m glad to see that Manuel has so articulately captured these leading-edge best practices for web application development in this time of great change in our thinking. The practical application of this book to web development will put you in a great position to produce software for the high demands of today’s world. 

      One thing I really, really like about this book is the abundance of useful diagrams and code snippets, all of which are profusely annotated with thoughtful comments! I would say that the barrier-to-entry to this book is not all that high—hastening to add that this is most emphatically not the same as saying that the contents are trifling.

      That’s right, this book reveals hard-won wisdom from an author who has clearly been in-the-trenches of sophisticated software development 🚀 Consider here an example or two from Reactive Web Applications: With Play, Akka, and Reactive Streams:

      Message passing 

      The purpose of actors is to model asynchronous processes by passing messages. Like humans in an organizational structure, actors pass each other information and react to certain types of messages. Unlike humans, actors will only reply to the set of messages that are handled in their receive method. If no wildcard case has been defined, they’ll boldly ignore a message for which no reaction has been defined, without so much as a log message. (This behavior can be quite distressing when you’re getting started with actors, so it’s a good idea to log any unhandled messages.) As you can see, one of the most important tasks of building an actor system is getting the message protocol right.

      And in elaborating on the apparent complexity of asynchronous programming, the author (Manuel Bernhardt) rightly notes that

      For a long time, writing asynchronous programs hasn’t been popular among developers because it can seem more difficult than writing good old synchronous programs. Instead of the ordered sequence of operations in a synchronous program, a request-handling procedure may end up being split into several pieces when written in an asynchronous fashion. 

      One of the popular ways of writing asynchronous code is to make use of callbacks. Because the program’s flow of execution isn’t blocked when waiting for an operation to complete (such as retrieving data from a remote web service), the developer needs to implement a callback method that’s executed once the data is available. Proponents of the threaded programming model would argue that when the processing is a bit more complicated, this leads to a style of code known as “callback hell.” 

      …..There are dozens of articles about callback hell and even one domain name ( dedicated to this issue, and it’s often encountered in larger Node.js ( applications. But writing asynchronous applications doesn’t need to be that hard.

      One thing I appreciated a lot was the liberal sprinkling of Scala tips throughout the pages. And the author (Manuel Bernhardt) did not copy snippets the Scaladoc and dump them; instead, he has clearly put a lot of thought into bringing out the relevance of the Scala tips in an original way ⛳ Here’s a typical Scala tip from the book:

      Scala tip: implicit parameters 

      Implicit parameters are a language feature of Scala that allows you to omit one or more arguments when calling a method. Implicit parameters are declared in the last parameter list of a function. For example, the index.scala.html template will be compiled to a Scala function that has a signature close to the following: 

      def indexTemplate(message: String)(implicit request: RequestHeader) 

      When the Scala compiler tries to compile this method, it will look for a value of the correct type in the implicit scope. This scope is defined by prepending the implicit keyword when declaring anonymous functions, as here with Action: 

      def index = Action { implicit request: RequestHeader =>   // request is now available in the implicit scope } 

      You don’t need to explicitly declare the type of request; the Scala compiler is smart enough to do so on its own and to infer the type.

      This is my kind of stuff 📫 Finally, for a fuller flavor of the book, here is the Table of Contents of this fine volume:

      1. Getting started with reactive web applications
      Chapter 1. Did you say reactive?
      Chapter 2. Your first reactive web application
      Chapter 3. Functional programming primer
      Chapter 4. Quick introduction to Play 

      2. Core concepts
      Chapter 5. Futures
      Chapter 6. Actors
      Chapter 7. Dealing with state
      Chapter 8. Responsive user interfaces 

      3. Advanced topics
      Chapter 9. Reactive Streams
      Chapter 10. Deploying reactive Play applications
      Chapter 11. Testing reactive web applications

      Appendix A. Installing the Play Framework
      Appendix B. Recommended reading
      Appendix C. Further reading Index

      Here is a link to the book’s accompanying code, available freely on Github.

      I look forward to more books by Manuel Bernhardt 💹

      5. Functional Reactive Programming by Stephen Blackheath and Anthony Jones (Manning Publications) 🔌

      In the end, here is another fine book that is replete with novel ideas: Functional Reactive Programming by Stephen Blackheath and Anthony Jones (Manning Publications). It is a joy to read on many counts, not the least of which is the authors’ endearingly disarming humor and the skill with which they tell their story. It’s all stuff, no fluff!

      Consider this excerpt for context—In his Foreword to the book, Heinrich Apfelmus (open source developer, and the author of the FRP library Reactive Banana, notes that

      Today, building graphical user interfaces and using object-oriented languages have become mainstream. Unfortunately, though, programming user interfaces is still surprisingly difficult. Code written in the currently predominant style, event-driven programming and the observer pattern, has an uncanny tendency to quickly evolve into an unmaintainable mess, commonly referred to as spaghetti code. Is there a better way? 

      I think it’s time for another step in the evolution of user interfaces and programming languages. In recent years, the ideas of functional programming and a (separate) programming style called functional reactive programming (FRP) have shown great promise in making it easier to develop any kind of interactive programs. This text is one of the first comprehensive introductions to functional reactive programming in book form.

      Nuggets of wisdom—on all things having to do with the reactive programming paradigm—await you in the pages of this book, presented with delightful humor. While this book does not read as evenly as the others in my list, it is nonetheless absolutely worth your time; there is coverage herein that I have simply not seen elsewhere; ignore Functional Reactive Programming at your own peril 😱

      Speaking of how the authors present profound ideas with disarmingly delightful humor, check out the punch line to this section in their book, where they talk about the sobering notion of getting the best bus performance out of your code:

      The Intel 64 and IA-32 Architectures Optimization Reference Manual is 800 pages long and contains advice like this (section 3.6.12): 

      If there is a blend of reads and writes on the bus, changing the code to separate these bus transactions into read phases and write phases can help performance. 

      Note, however, that the order of read and write operations on the bus is not the same as it appears in the program. 

      Bus latency for fetching a cache line of data can vary as a function of the access stride of data references. In general, bus latency will increase in response to increasing values of the stride of successive cache misses. Independently, bus latency will also increase as a function of increasing bus queue depths (the number of outstanding bus requests of a given transaction type). 

      Did you get that? 😆

      Coming to a topic that is near and dear to my heart—achieving compositionality in software design—the authors (the Australia-based duo of Stephen Blackheath and Anthony Jones) thoughtfully point out a (logically consistent) strategy for slaying the complexity monster, to which I’ll simply add, being open and receptive to undogmatically using all the paradigms and tools at our disposal:

      5.2.1. Compositionality
      A major claim of FRP is that it tames complexity. It does this in a specific way: by enforcing something called compositionality. 

      5.2.1. When complexity gets out of control
      We all know this from experience: the complexity of a program can get out of control. When complex parts interact in complex ways, the complexity can compound, with the result that overall software complexity grows exponentially with program size

      5.2.1. Reductionism and engineering
      Software development is a form of engineering, and engineering is based on the philosophy of reductionism. This methodology is powerful; it has been enormously successful at providing us with technology that has transformed the way we do almost everything. 

      The reductionist approach to engineering has four steps: 

      1.  Start with a complex problem. 2.  Break the problem into simpler parts. 3.  Solve the parts. 4.  Compose the parts of the solution into a whole. 

      Step 4 is where we get into trouble. Reductionism has a hidden assumption of compositionality: that the nature of the parts doesn’t change when we compose them. When this isn’t true, we can fail badly. If we wrongly assume compositionality, then we have committed a logical fallacy called the fallacy of composition. What is true of the parts in isolation may not be true when they’re combined. 

      For example: If someone stands up at a football game, they can see better. Therefore if everyone stands up, everyone can see better. Cells are invisible. I am composed of cells. Therefore I am invisible. If I ignore my problems for an hour, they go away for an hour. Therefore if I ignore them for two hours, they go away for two hours. Therefore… 

      Event propagation is a widely used “glue” for composing software components. FRP gives us event propagation with guaranteed compositionality. By imposing compositionality, FRP makes the assumptions of reductionism valid, and in this way, it makes software engineering work the way it should

      Last, but not the least, don’t miss the inimitable and insightful coverage of, as the authors put it, Banishing the Six Plagues of Listeners. The preamble goes like this:

      What could possibly go wrong with the wonderful observer pattern? Uh…yeah. We’ve identified six sources of bugs with listeners; see figure 1.3. FRP banishes all of them…

      Here is a link to the book’s accompanying code, available freely on Github.

      Lest I forget, here is this fine book’s (brief) TOC:

      Chapter 1. Stop listening!
      Chapter 2. Core FRP
      Chapter 3. Some everyday widget stuff
      Chapter 4. Writing a real application
      Chapter 5. New concepts
      Chapter 6. FRP on the web
      Chapter 7. Switch
      Chapter 8. Operational primitives
      Chapter 9. Continuous time
      Chapter 10. Battle of the paradigms
      Chapter 11. Programming in the real world
      Chapter 12. Helpers and patterns
      Chapter 13. Refactoring
      Chapter 14. Adding FRP to existing projects
      Chapter 15. Future directions 

      Appendix A. Sodium API
      Appendix B. The six plagues of event handling
      Appendix C. Comparison of FRP systems
      Appendix D. A section for managers
      Appendix E. Denotational semantics of Sodium 


      Enough said. Now start reading, and please don’t stop until, um, you see the fabled stop sign 📵 Wrap-up is next…

      So this is where we bring our journey to a close. I hope that our brief foray through the landscape of reactive programming resources has sparked your interest in this profound area; if you were already interested, but continuing to look for reactive programming resources, then I hope that these ideas will be of some use to you. Truth be told, our journey has only begun.  And yes, you may go past the glaring stop sign at this time—traffic signs remind me of image processing which, in turn, brings back exciting memories of my research and dissertation on pattern recognition methods using neural network algorithms, back in the day, when I was a graduate student, based in College Station (Texas). But I digress 🌈

      The Road goes ever on and on,
      Down from the door where it began.

      Now far ahead the Road has gone,

      And I must follow, if I can,

      Pursuing it with eager feet,

      Until it joins some larger way

      Where many paths and errands meet.

      And whither then? I cannot say.

      ~ J.R.R. Tolkien, The Fellowship of the Rings 

      Bon voyage through the reactive programming landscape, as well as, of course, through the vistas of the Elegant Universe 🐳


      1. As the author of this blog, I do not (as a matter of principle) edit my posts after, well, posting them; I will, on occasion, revisit and clean up grammatical mistakes, or perhaps add links, update stale links, but that's about it 😉

        Having said that, I forgot to add something that I had intended to include in my review of the fine book "Functional Reactive Programming" by Stephen Blackheath and Anthony Jones, so I'll mention that by way of this comment: Namely, of all the books reviewed in this post, this is the only one whose accompanying code I did not get the opportunity to study with any depth or rigor. By the same token, I encourage all those who are interested to delve into it, using the provided link (to the book's accompanying code (available freely on Github)). I hope to do the same, one day…

        Enjoy 🙂

      2. Wanted to transplant here, from the fine Scala Users Group (, a good question by the reader Francososa, who had commented there on this post:

        – Thank you for pointing out these resources with reviews! As someone coming from Python I have two questions:

        – How do you recommend to get started on Reactive Programming? I'm going through Programming in Scala and Functional Programming in Scala
        Will code in some of these books, like Reactive Web Applications, still work even if the libraries used are in newer versions.

        – I wanted to buy Reactive Web Applications but some of the comments indicated that the code wasn't working anymore because of the Play version it used.

        My reply was the following, which I wish to share here, as it may reach a larger audience:

        – In turn, I thank you, Francososa, for kindly appreciating my reviews of the finest books on Reactive Programming!

        It just so happens that I've spent a fair amount of time writing Python code, and found it to be an incredibly productive language. For most of my development work, however, I use Java and Scala since these languages are easier to maintain and scale well as your code base grows.

        – Having said, I applaud your enthusiasm for wanting to embrace the Reactive Programming paradigm. Both of the books you mention are superb. To those two, I would definitely add a third one, which you should read along with the fine book by Martin Odersky; the book FP in Scala is awesome, though a bit advanced. The book I'm suggesting is entitled Programming Scala: Scalability = Functional Programming + Objects (O'Reilly), by Dean Wampler and Alex Payne. As I had noted in my review of that book, many many moons ago, "If you're going to read only one book on Scala, make it this one…" and I still stand by my words. Feel free to checkout my musings on this very subject, to get a better sense of the resources available to you on Scala programming, by visiting my post on the "Best Scala Books".

        – You're doing a very sensible thing by becoming proficient in Scala: Keep on reading!

        – To your second question, getting the versions of libraries all lined up, and working happily with each other, can be a challenge at time, in fact, more often than one would wish for it to be the case. I suggest that you visit the website each (where readers ask questions of the author(s) regarding the pragmatics, etc., of getting the accompanying code up and running) that is dedicated to the book whose code you're wanting to deploy and run locally. Manning Publishers do a great job, in general, of maintaining such archives, so please help benefit yourself by going through the archived threads (Q&A format). Good luck!

      3. Wanted to transplant here, from the fine Scala Users Group (, another remarkably incisive question by the reader Yawar Amin, who had commented there on this post as follows:

        – Hi, thanks for the in-depth reviews. I should just point out that the last book, Functional Reactive Programming, is not like the others. It deals with reactive programming purely as a change propagation mechanism (in the same way that event listeners are used to propagate change). The other books all mean 'reactive programming' in the sense of 'building resilient, fault-tolerant systems' which is really quite something different and more akin to Erlang's actor model than to change propagation.

        In turn, my reply was the following, which I also wish to share here, as it may reach a larger audience:

        – Thanks for the spot-on comment, Yawar. I can only wish that more readers would lavish the close attention (which you have clearly brought to bear) in reading my posts!

        – Yes, you are absolutely right when you point out that, "…the last book, Functional Reactive Programming, is not like the others. It deals with reactive programming purely as a change propagation mechanism (in the same way that event listeners are used to propagate change)". I could not have said it better, so thank you, again, for clarifying.

        – I simply can't tell you just how gratifying it is when readers (like you) bring admirable perspicacity, provide feedback, and help everyone grow their understanding of these decidedly profound (and exciting!) subjects in the process. Kudos!

      4. – A big thanks to each one of you—to be precise, the 39,559 unique visitors—who made time out of their busy schedules to read my posted essays.
        – I leave you with a friendly reminder: Please don't be shy, we're all in this together – Freely share your reaction, thoughts, comments here!

      5. – Thanks for the spot-on comment, Steve. I have read portions of the book you mention (i.e. Clojure Reactive Programming: How to Develop Concurrent and Asynchronous Applications with Clojure, by Leonardo Borges) since I have (way) more than a passing interest in the lovely (Lisp-for-the-JVM) language that is Clojure 🙂
        – In fact, I debated mentioning this very book in my review, but decided not to, simply because I have not put in enough serious hours into this book about reactive programming, and which has a decidedly Clojure twist. So I am not familiar enough with its content to muse about it…
        – By the same token, I really do appreciate your thoughtful note, and of course for dropping by my blog and checking out my latest post 🙂

      6. Positive site, where did u come up with the information on this posting signagecloud I have read a few of the articles on your website now, and I really like your style. Thanks a million and please keep up the effective work.

      7. – Thanks so much, Kiara, for that very thoughtful note and great feedback!

        – While it may seem trite if I say so, but the fact is that comments from readers like you make my day, every day 🙂

        – As to your question ("where did u come up with the information on this posting")—that's an excellent and deep question because it goes to the heart of what I do for this blog that readers like you take some of your precious time out to read—my response is something like this:

        – So my answer could get really longwinded, but in a nutshell, I use a really old-fashioned approach: I deliberately set aside time (and this is often "weeks" and may sometimes even be "months") at a time, of course amortized over the span of time, to pore over "the material" (books, magazines, software, tools, etc.) , get the computer programs up and running, try them, experiment with variations of those computer programs (once I've got them up and running, of course), and so on.

        – I could go into more details, but I don't want to bore you either! Should you and other readers be interested in those details, though, then by all means please lemme know via your comments right here – I'll be delighted to share all the details. After all, as the impresario of the Programming Digressions, I'm here to serve you all!

        – By the way, I nearly forgot to mention something: Equally important in connection with coming up with the information on postings such as this one—and this is where my dear readers, you all, come in—I really spend a lot of time in formulating and assessing just how readable, approachable, engaging, worthwhile, enjoyable, reliable, user-friendly, etc., any given resource (aka "the material") truly is…

        – As to your comment ("I really like your style"), all I can say is, thank you so much! Glad you enjoyed not only the content of the essay, but also the style.

        – If you like the style of the essays here, I think you'll also really like a brand new series of essays—three postings to be exact—of which the latest one I posted just yesterday while I'm visiting my Mom in Houston, since I'm based in another city (Austin) in Texas!

        This new series of essays is all about exploring the amazing riches that are in store for readers like you – It's a book entitled Plato and the Nerd: The Creative Partnership of Humans and Technology (The MIT Press) by Edward Ashford Lee

        – Frankly, it's an unbelievably great book, which is why I've devoted a whopping three essays—yep, an unprecedented three essays—to a single book, such is its uniqueness and richness of content:

        First essay is simply entitled Plato And The Nerd, and is available at this link.

        Second essay is entitled a bit more fancifully (Return of Plato And The Nerd) and is available at this link.

        Third essay is entitled even more fancifully lol (Plato And The Nerd Strikes Back) and is available at this link. And yes, I'm a die-hard Star Wars fan 😉

        – Of course, this is your blog as much as it is mine, so please feel free to cruise around the blog and explore all the other essays as well 🙂

      8. – I wished to add… If you continue liking the content and style of the postings, Kiara, do please spread the word, won't you? Engaged readers like you, and your great feedback, make Programming Digressions the lively community of readers that it's truly become over the years… 

        – Please keep all those great suggestions (and encouragement) coming; it keep this blogger motivated to continue writing more essays to post here – Thank you!!!

        – Much as I said above, and I'll say it again, because I truly mean it: Comments from readers like you really make my day, every day 🙂

      9. This incorporates affecting specifically on one's connections, otherworldly, budgetary, and wellbeing states of mind and convictions about what one can and can not by any stretch of the imagination control to enhance these regions. Best LSAT Book Review

      10. I want to dive into reactive + functional programming and also akka. I have found your blog about recommended books very useful. I will be reading these books in the order you mentioned them. Congrats from Argentina and keep up the good work man!.

      11. continuously i used to read smaller articles or reviews
        that also clear their motive, and that is also happening
        with this article which I am reading here.

      12. I visited many web pages however the audio feature
        for audio songs existing at this website is genuinely excellent.

      13. Hi there I am so happy I found your website, I really
        found you by accident, while I was researching on Askjeeve for something else, Anyways
        I am here now and would just like to say thanks for a marvelous
        post and a all round entertaining blog (I also love the theme/design), I don't have time
        to read through it all at the moment but I have bookmarked it and also added your RSS feeds, so when I have time I will be back to read much more, Please do keep up the superb work.

      14. I absolutely love your site.. Pleasant colors & theme.
        Did you build this amazing site yourself? Please reply back as I?m hoping to create
        my very own site and want to learn where you got this from or
        just what the theme is called. Appreciate it!

      15. I am sure this piece of writing has touched all the internet users, its really really pleasant article on building up new weblog.

      16. I am continuously browsing online for articles that
        can facilitate me. Thank you!

      17. The very next time I read a blog, Hopefully it won't fail me just as much as
        this one. I mean, Yes, it was my choice to read, nonetheless
        I actually believed you'd have something useful to talk about.
        All I hear is a bunch of complaining about something that
        you could possibly fix if you were not too busy looking for attention.

      18. My partner and I absolutely love your blog and find almost
        all of your post's to be just what I'm looking for.
        can you offer guest writers to write content for you personally?
        I wouldn't mind composing a post or elaborating on a lot of the subjects you write with regards to here.
        Again, awesome site!

      19. Thanks, I have recently been looking for info approximately this topic for ages and yours is the
        best I have discovered so far. However, what in regards to the conclusion?
        Are you positive about the source?

      20. Hello friends, how is the whole thing, and what you desire to say regarding this piece of writing, in my view its truly amazing
        for me.

      21. I do consider all of the ideas you've introduced to your post.
        They're very convincing and will definitely work.
        Still, the posts are too brief for novices. May you please extend them a little from subsequent time?

        Thanks for the post.

      22. If some one wants to be updated with newest technologies after that he
        must be pay a quick visit this web page and be up to date all the

      23. Some genuinely rattling work on behalf of the owner of this web site,
        utterly outstanding subject material.

      24. Aw, this was a very nice post. Finding the time and actual effort
        to produce a good article? but what can I say? I put things off a lot and don't seem to
        get nearly anything done.

      25. When someone writes an paragraph he/she maintains
        the plan of a user in his/her brain that how a user can be aware of it.
        So that's why this post is amazing. Thanks!

      26. Heya just wanted to give you a brief heads up and let you know a few of the images aren't loading correctly.
        I'm not sure why but I think its a linking issue. I've tried it in two different browsers
        and both show the same outcome.

      27. Hi Akram,

        Thanks for this post!

        I'm just curious about one of your observations for "Reactive Messaging Patterns with the Actor Model: Applications and Integration in Scala and Akka". You mention:

        "Seldom have I seen cross-referencing done by a publisher to such great effect!"

        I was working on a book, and was just curious about that statement. I went to that ebook, and I found this example:

        Does this paragraph capture this cross-referencing? There are many links to places in the books where the mentioned concepts are defined. Or you had something else in mind?

        Thank you!

      28. So, determine if you will need those features within the
        package of Sacramento wedding photographers or not. As
        a result we have a perfect interpretation of the was
        authored by the composer, a fantastic fusion of
        both technique and emotion, the true musical masterpiece.
        I didn't even no the best way to tune finished . a lot less know where you can put
        my fingers about the fretboard so I could play a note.

      29. Oh my goodness! Awesome article dude! Thank you so much, However I am having issues with
        your RSS. I don't know why I can't join it. Is there anybody having identical RSS problems?
        Anyone that knows the solution can you kindly respond? Thanx!!

      30. Greetings! Very useful advice within this article! It's the little changes that make
        the greatest changes. Thanks for sharing!

      31. Good day very cool web site!! Man .. Excellent .. Wonderful ..
        I will bookmark your blog and take the feeds additionally?
        I'm satisfied to find soo many helpful informatiokn here within the submit,
        we need develop extra strategies on thos regard, thank
        you for sharing. . . . . .

      32. Maravilhosa itens de você, cara. Eu tenho tome nota suas coisas antes de e você está simplesmente também
        maravilhoso . Eu realmente como o que você tem comprou
        aqui , certamente como o que você está afirmando e a
        melhor maneira através do qual diz. Está cometendo-divertido
        e você continuar a cuidar para manter- sábio.

        Eu cant esperar para aprender muito mais de você.
        Isto é na verdade um fantástico site .

      33. Uma pessoa necessariamente ajuda tornar severamente
        posts Talvez estado. Isto é o primeiro tempo eu frequentava sua página site e até agora ?
        Eu espantado com o análise você fez para criar este particular submeter extraordinária.
        Excelente tarefa !

      34. Olá ! Você sabe se eles fazem qualquer plugins para proteger contra hackers?

        Eu tenho umas paranoias sobre perder tudo que trabalhei duro.
        Qualquer dicas?

      35. Thank you for this post! I found this via your Amazon review of the Vaughn book. I am currently in an Akka / reactive deep dive, and looking for my next read. From what I read here, I can see that you are knowledgable and passionate about the subject, so I will probably be back!

        I have a question: I have not read “Enterprise Integration Patterns”, though it does sound like a worthwhile read. I am currently working on an Akka-heavy system (and loving it), so I want to read “Reactive Messaging Patterns with the Actor Model”. Would I be better served by reading “Enterprise Integration Patterns” first? I’d like to read both, but would also appreciate being able to start applying more reactive patterns to my Akka application sooner than I imagine it would take me to digest EIP.

        • – Awesome to hear that, Ross! The way I see it, the massive book you mention (“Enterprise Integration Patterns”) is simply indispensable. Having said that, it’s heft requires hours and hours of devoted time in reading it. I recommend you read it in parallel with “Reactive Messaging Patterns with the Actor Model”.
          – Also be sure to check out a much newer set of books I reviewed in this area: Best Reactive Programming Books (2019).
          – And yes, you guessed it: I do think that reactive programming is right up there with AI/ML and Microservices in terms of awesomeness!

          • Cool… thank you for your response. I ended up doing just that – and am now reading both “Enterprise Integration Patterns” and “Reactive Messaging Patterns with the Actor Model” in parallel.

            I took a look at your other list, and was delighted to find that you had “Reactive Application Development” in that list, as that is the book that I had just finished reading before I reached out to you. I did find that one to be a practical intro to the subject for me. (Well, at least a more thorough intro after hours of web research and application development).

      Leave a Reply to AnonymousCancel reply

      This site uses Akismet to reduce spam. Learn how your comment data is processed.