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 liveThink about directionWonder why you haven’t beforeIf you are confused, check with the sunCarry a compass to help you alongYour feet are going to be on the groundYour head is there to move you around đ~ R.E.M (lyrics from Stand)
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.
- Reactive Design Patterns by Roland Kuhn, Brian Hanafee, and Jamie Allen (Manning Publications) đ°
- Functional and Reactive Domain Modeling by Debasish Ghosh. (Manning Publications) â°
- Reactive Messaging Patterns with the Actor Model: Applications and Integration in Scala and Akka by Vaughn Vernon (Addison-Wesley Professional) đ
- Reactive Web Applications: With Play, Akka, and Reactive Streams by Manuel Bernhardt (Manning Publications) đ¶
- Functional Reactive Programming by Stephen Blackheath and Anthony Jones (Manning Publications) đ
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.
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
Index
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.”
https://pragprog.com/book/mnee/release-it
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 elementsâlyricism, 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.
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
2.1.3.1. 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
Index
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?
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
Responsive
Resilient
Elastic
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
Supervision
Remoting
Clustering
Testing Actors
The CompletableApp
Summary
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
Message
Pipes and Filters
Message Router
Message Translator
Message Endpoint
Summary
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
Summary
Chapter 6 Message Construction
Command Message
Document Message
Managing Flow and Process
Event Message
Request-Reply
Return Address
Correlation Identifier
Message Sequence
Message Expiration
Format Indicator
Summary
Chapter 7 Message Routing
Content-Based Router
Message Filter
Dynamic Router
Recipient List
Splitter
Aggregator
Resequencer
Composed Message Processor
Scatter-Gather
Routing Slip
Process Manager
Message Broker
Summary
Chapter 8 Message Transformation
Envelope Wrapper
Content Enricher
Immutable DoctorVisitCompleted
Should the AccountingEnricherDispatcher Be Local?
Content Filter
Claim Check
Normalizer
Canonical Message Model
Actor Systems Require a Canon
Summary
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
Summary
Chapter 10 System Management and Infrastructure
Control Bus
Detour
Wire Tap
Message Metadata/ History
Message Journal/ Store
Smart Proxy
Test Message
Channel Purger
Summary
Appendix A Dotsero: An Akka-like Toolkit for .NET
Dotsero Actor System
Actors Using C# and .NET
Dotsero Implementation
Summary
Bibliography
Index
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.
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 (http://callbackhell.com) dedicated to this issue, and itâs often encountered in larger Node.js (http://nodejs.org) 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
Index
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
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 đ
Although it's Clojure specific, I'd put this book on the list as well https://www.amazon.com/Clojure-Reactive-Programming-Asynchronous-Applications/dp/1783986662
Wanted to transplant here, from the fine Scala Users Group (users.scala-lang.org), 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!
Wanted to transplant here, from the fine Scala Users Group (users.scala-lang.org), 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!
– 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!
– 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 đ
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.
– 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 đ
– 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 đ
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
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!.
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.
I visited many web pages however the audio feature
for audio songs existing at this website is genuinely excellent.
yes
Much obliged to you, for sharing those brilliantly expressive perceptions. As the reader of this blog, I'll attempt to do some equity in reacting; there's a great deal that you've pressed in articulating the critical imperatives of, as you pleasantly put it. Keep Sharing
Big Data Hadoop online training in Hyderabad
Hadoop online training in Bangalore
This text is invaluable. How can I find out more?
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.
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!
I am sure this piece of writing has touched all the internet users, its really really pleasant article on building up new weblog.
I am continuously browsing online for articles that
can facilitate me. Thank you!
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.
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!
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?
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.
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.
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
time.
Some genuinely rattling work on behalf of the owner of this web site,
utterly outstanding subject material.
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.
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!
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.
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: https://imgur.com/Oi4jGwm.
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!
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.
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!!
Greetings! Very useful advice within this article! It's the little changes that make
the greatest changes. Thanks for sharing!
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. . . . . .
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 .
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 !
OlĂĄ ! VocĂȘ sabe se eles fazem qualquer plugins para proteger contra hackers?
Eu tenho umas paranoias sobre perder tudo que trabalhei duro.
Qualquer dicas?
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).
very nice and informational article it make me feel to appreciate your efforts for this wonderful article thanks for sharing this with us.
women nighty
night suit for women
net nighty
babydoll nighty
babydoll dress
women nighty dress
sexy lingerie
bikini
bra panty
redokcart