Thursday, August 3, 2017

Best Reactive Programming Books

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)
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)
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)

This Illustration 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...


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


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!


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, Third Edition A comprehensive step-by-step guide 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 πŸ˜‚


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 πŸ’Ή


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. Although it's Clojure specific, I'd put this book on the list as well

    1. - 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 :)

  3. This comment has been removed by the author.

  4. 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!

  5. 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!

  6. - 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!