Reactive Application Development teaches you how to build reactive applications using the Typesafe stack. The book starts with an architectural overview that teaches you how a reactive application works and shows you where the various technologies you'll use fit into the system. Then you'll tackle the many moving pieces of a reactive application, learning to apply patterns such as CQRS, Event Sourcing, Microservices and more. Along the way, you'll learn how to build distributed domain models for reactive applications and clustered actor systems for elasticity and resilience, as well as how to integrate reactive systems with traditional architectures. You'll also pick up techniques for testing reactive applications, refactoring existing systems, and designing RESTful APIs.
Part 1: Fundamentals
1. What is a Reactive Application?
1.1. Why do I need a reactive application?
1.1.1. Distributed Computing
1.1.2. Cloud Computing
1.2. Web shopping cart: complexity beneath the surface
1.2.1. Monolithic architecture: difficult to distribute
1.2.2. Reactive architecture: distributable by default
1.2.3. Understanding the Reactive Architecture
1.2.4. Monolithic shopping cart: creating an order
1.2.5. Event Sourcing: A banking example
1.2.6. Reactive shopping cart: creating an order with event sourcing
1.3. What are reactive applications reacting to?
1.4. What You Will Learn in this book
1.4.1. Asynchronous communication with loosely coupled design
1.4.2. Elastic
1.4.3. Resilient
1.4.4. Responsive
1.4.5. Testing
1.5. Summary
2. Getting Started with Akka
2.1. Understanding Messages and Actors
2.1.1. Moving from Functions to Actors
2.1.2. Modeling the Domain with Actors and Messages
2.1.3. Defining the Messages
2.1.4. Defining the Actors
2.2. Setting up the Example Project
2.3. Starting the Actor System
2.3.1. Creating the Driver
2.3.2. Running the driver
2.4. Distributing the Actors over Multiple Systems
2.4.1. Distributing to two JVMs
2.4.2. Configuring for Remote Actors
2.4.3. Setting up the Drivers
2.4.4. Running the Distributed Actors
2.5. Scaling with Multiple Actors
2.5.1. Traditional Alternatives
2.5.2. Routing as an Actor Function
2.6. Creating a Pool of Actors
2.6.1. Adding the Pool Router
2.6.2. Running the Pooled Actor System
2.7. Scaling with Multiple-Actor Systems
2.7.1. Adding the Group Router
2.7.2. Running the Multiple Actor Systems
2.8. Applying Reactive Principles
2.9. Summary
3. Understanding Akka
3.1. What is Akka?
3.2. Akka Today
3.2.1. Becoming responsive
3.2.2. Retaining data reliably
3.2.3. Increasing Resiliency and Elasticity
3.2.4. Supporting Big Data with Spark
3.3. Akka terminology
3.3.1. Concurrency and Parallelism
3.3.2. Asynchronous and Synchronous
3.3.3. Contention
3.3.4. Share Nothing
3.4. The Actor Model
3.4.1. State
3.4.2. Actor Reference
3.4.3. Asynchronous Message Passing
3.4.4. The Mailbox
3.4.5. Behavior and the Receive Loop
3.4.6. Supervision
3.5. The Actor System
3.5.1. Hierarchical Structure
3.5.2. Supervision
3.5.3. Actor Paths
3.5.4. Actor Lifecycle
3.5.5. Microkernel Container
3.6. Summary
Part 2: Building a Reactive Application
4. Mapping from Domain to Toolkit
4.1. Designing from a domain model
4.1.1. A better solution
4.1.2. Moving from analogy to application
4.1.3. Creating the catalog
4.2. Becoming message-driven
4.3. Controlling actor state with messages
4.3.1. Sending messages to yourself
4.3.2. Changing behavior with state
4.3.3. Managing more complex interactions
4.3.4. Keeping it simple
4.3.5. Running the Application
4.3.6. Reviewing progress
4.4. Increasing elasticity
4.4.1. Akka Routing
4.4.2. Dispatchers
4.4.3. Running the Application with routers
4.5. Resilience
4.5.1. Faulty Librarian Actor
4.5.2. Running the Faulty Application
4.5.3. Librarian Supervision
4.5.4. Running the Application with resilient supervision
4.6. Summary
5. Domain-Driven Design
5.1. What is domain-driven design?
5.1.1. The big ball of mud
5.1.2. Bounded Context
5.1.3. Ubiquitous language
5.1.4. Entities, Aggregates and Value Objects
5.1.5. Services, Repositories and Factories
5.1.6. Anticorruption Layers
5.1.7. Layered Architecture
5.1.8. Sagas
5.1.9. Shared Kernel
5.2. An Actor-based domain
5.2.1. A Simple Akka Aircraft Domain
5.2.2. The actor
5.2.3. The Process Manager
5.3. Summary
6. Using Remote Actors
6.1. Refactoring to a distributed system
6.1.1. Splitting into multiple actor systems
6.1.2. Structuring with SBT
6.2. Configuring the applications
6.2.1. Creating the first driver application
6.2.2. Introducing application.conf
6.2.3. Using HOCON
6.2.4. Configuring the driver application
6.3. Remoting with Akka
6.3.1. Constructing remote references
6.3.2. Resolving the references
6.3.3. Replacing clients with peers
6.3.4. Creating another driver
6.4. Running the distributed example
6.4.1. Starting the customer application
6.4.2. Starting the RareBooks application
6.4.3. Creating some customers
6.4.4. Reviewing the results
6.5. Reliability in distributed systems
6.5.1. Reliability as a design parameter
6.5.2. Akka Guarantees
6.6. Summary
7. Reactive Streaming
7.1. Buffering too many messages
7.2. Defending with backpressure
7.2.1. Stopping and waiting
7.2.2. Signaling for more than one message
7.2.3. Controlling the stream
7.3. Streaming with Akka
7.3.1. Adding streams to a project
7.3.2. Creating a stream Source from a file
7.3.3. Transforming the stream
7.3.4. Converting the stream into actor messages
7.3.5. Putting it together
7.4. Introducing Reactive Streams
7.4.1. Creating a Reactive Stream
7.4.2. Consuming the Reactive Stream
7.4.3. Building applications with streaming
7.5. Summary
8. CQRS and Event Sourcing
8.1. Driving Factors Towards CQRS/ES
8.1.1. ACID Transactions
8.1.2. Traditional RDBMS Lack of Sharding
8.1.3. CRUD
8.2. CQRS Origins : Command, Queries, and Two Distinct Paths
8.3. The C in CQRS
8.3.1. What is a Command?
8.3.2. Rejection
8.3.3. Atomicity
8.3.4. Jack of All Trades, Master of None
8.3.5. Lack of Behavior
8.3.6. Order Example- The Order Commands
8.3.7. Nonbreaking Command Validation
8.3.8. Conflict Resolution
8.4. The Q in CQRS
8.4.1. Impedance Mismatch
8.4.2. What is a Query?
8.4.3. Dynamic Queries Not Needed
8.4.4. Relational versus NoSQL
8.5. Event Sourcing
8.5.1. What is an Event?
8.5.2. It is all about Behavior
8.5.3. Life Beyond Distributed Transactions
8.5.4. The Order Example
8.5.5. Consistency Revisited
8.5.6. Retry Patterns (Reference Reactive Design Patterns)
8.5.7. Command Sourcing vs. Event Sourcing
8.6. Summary
9. A Reactive Interface
9.1. What is a Reactive Interface
9.1.1. The API Layer
9.1.2. The Headless API
9.2. Expressive RESTful Interfaces
9.2.1. JSON vs XML
9.2.2. Expressive RESTful Interface URLs
9.2.3. Location
9.3. Choosing Your Reactive API Library
9.3.1. Play
9.3.2. Opinionation
9.3.3. Application Structure
9.3.4. A Simple Route
9.3.5. Nonblocking Service Interfaces
9.4. Akka HTTP: A simple CQRS-esque service
9.5. Lagom: The order example
9.6. Play vs Akka HTTP vs Lagom
9.7. Summary
10. Production Readiness
10.1. Testing a Reactive application
10.1.1. Identifying test patterns
10.1.2. Testing concurrent behivor
10.2. Securing the application
10.2.1. Taking threats in STRIDE
10.2.2. Barbarians at the gate
10.2.3. Adding HTTPS
10.3. Logging actors
10.3.1. Stackable logs
10.3.2. Configuring the log system
10.4. Tracing messages
10.4.1. Collecting trace data with the Dapper pattern
10.4.2. Reducing dependencies with OpenTracing
10.4.3. Integrating OpenTracing with Akka
10.4.4. Finding pathways with the spider pattern
10.5. Monitoring a Reactive application
10.5.1. Monitoring core metrics with Lightbend Monitoring
10.5.2. Creating a custom metric with Kamon
10.6. Handling failure
10.6.1. Deciding what to restart
10.6.2. Routing considerations
10.6.3. Recovering, to a point
10.7. Deploying to a cloud
10.7.1. Isolating the factors
10.7.2. Dockerizing actors
10.7.3. Other packaging options
10.8. Summary
About the Technology
Modern distributed applications run in environments that may include thousands of processors, web and mobile clients, hybrid cloud deployments, and petabytes of data. The traditional patterns and practices for enterprise application development simply can't deliver the millisecond response times and near-perfect reliability these systems require. Reactive applications meet these demands by employing a loosely-coupled system of independent, isolated components that communicate via asynchronous message passing. These systems are highly responsive to changes in load, extremely fault tolerant through self-healing, and designed to elastically scale. For developers working in JVM-based systems, the Typesafe stack, anchored by the Java and Scala programming languages and the Akka toolkit and runtime, gives developers the tools to build a production-ready reactive application platform.
What's inside
- Learn to build production-quality distributed applications that apply reactive design patterns
- Incorporate Actor-based scalable parallelism using Akka
- Design distributed domain models that are elastic
- Build systems that are fault-tolerant and self-healing
- Employ techniques such as CQRS and Event Sourcing to capture behavior
- Efficiently handle large volumes of data and heavy user demand
About the reader
Readers should have some familiarity with traditional distributed application architecture and be comfortable reading Java and Scala code. Some familiarity with Akka and functional programming is helpful but not required.
About the authors
Duncan DeVore works at Typesafe, is a committer on the original event-sourced project that became Akka Persistence, and maintains the Akka Persistence Mongo Plugin. Sean Walsh is CEO of reactibility.com and a seasoned architect with deep expertise in the Typesafe stack. He consults and evangelizes about reactive architectures. Together, Duncan and Sean deployed one of the first large scale Reactive applications to production. Brian Hanafee is a Principal Systems Architect at a large financial institution, with experience building reliable and secure web-based applications and backing services for millions of customers.
FREE domestic shipping on three or more pBooks