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
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. What is Akka?
3.1. What is Akka?
3.2. Akka Today
3.2.1. Message Driven
3.2.2. Resilient and Elastic
3.2.3. Responsive
3.2.4. Big Data
3.3. Akka terminology
3.3.1. Concurrency and Parallelism
3.3.2. Asynchronous and Synchronous
3.3.3. Blocking, Registered Callback, Future, and Message Passing
3.3.4. Contention
3.3.5. 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
4. Akka Basic Toolkit
4.1. Bookstore Analogy
4.2. Message Driven
4.2.1. Immutable Messages
4.2.2. Asynchronous Concurrency with Actors
4.2.3. Running the Application
4.3. Elasticity
4.3.1. Akka Routing
4.3.2. Librarian Router
4.3.3. Running the Application
4.4. Resilience
4.4.1. Faulty Librarian Actor
4.4.2. Running the Faulty Application
4.4.3. Librarian Supervision
4.4.4. Running the Application
4.5. 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. Anti-corruption 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
Part 2: Building A Reactive Application
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.1.1. Unexpected buffering
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. Atomic, Consistent, Isolated, Durable Transactions (ACID)
8.1.2. Traditional RDBMS - Lack of Sharding
8.1.3. CRUD
8.2. CQRS Origins
8.2.1. Command, Queries, and Two Distinct Paths
8.3. The "C" in CQRS
8.3.1. What is a Command?
8.3.2. Rejection Oh Noes!
8.3.3. Atomicity
8.3.4. Jack of All Trades, Master of None
8.3.5. Lack of Behavior
8.3.6. The Order Example Part 1 - The Order Commands
8.3.7. Non Breaking 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 - No More Pain
8.4.4. Relational vs NoSQL
8.5. Event Sourcing
8.5.1. What is an Event?
8.5.2. It's all about Behavior
8.5.3. Life Beyond Distributed Transactions
8.5.4. The Order Example Part 2
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. Non-Blocking Service Interfaces
9.4. Akka-Http
9.4.1. A Simple CQRS-esque Akka-Http Service
9.5. Lagom
9.5.1. The Lagom 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.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. Integrating with Akka
10.4.3. 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