Reactive Application Development
Duncan K. DeVore, Sean Walsh, and Brian Hanafee
  • MEAP began December 2014
  • Publication in January 2018 (estimated)
  • ISBN 9781617292460
  • 400 pages (estimated)
  • printed in black & white

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.

Table of Contents detailed table of contents

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

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

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


Manning Early Access Program (MEAP) Read chapters as they are written, get the finished eBook as soon as it’s ready, and receive the pBook long before it's in bookstores.
Buy
MEAP combo $49.99 pBook + eBook + liveBook
MEAP eBook $39.99 pdf + ePub + kindle + liveBook

FREE domestic shipping on three or more pBooks