Akka in Practice: Designing Actor-based Applications
1. AKKA
in PRACTICE
Real World Application Design Patterns
for the Intermediate Akka Developer
November 6th 2013
!@rayroestenburg ✉ ray@scalapenos.com
✉ age@scalapenos.com
!@agemooij
2. Agenda
➡ BOOTING UP
➡ THE RECEPTIONIST
➡ CREATING CHILDREN
➡ BECOME
➡ CONFIGURATION BY EXTENSION
➡ STREAMING EVENTS
➡ DOING REQUESTS/RESPONSE
3. Booting Up:
➡ How do we start up our Akka app?
➡ Where do we create the actor system?
Akka applications don’t need any containers!
st wri
t we ju
ethod?”
a main m
te
hy don’
“W
y not?”
ure, wh
“S
5. The Receptionist:
➡ How do we get Akka to actually do some work?
➡ We need to talk to it from the “outside”
➡ We need a “receptionist” to take our calls
“Just u
cket!”
se a so
Akka IO supports TCP, UDP, and HTTP
We will use Spray, a.k.a. akka-http
8. Creating Children:
➡ Every actor should do one thing and one thing only!
➡ When it all gets too much, use child labor!
➡ Children help with separation of concerns
➡ Use supervision to deal with failure
9. Creating Children:
➡ Create a child to do the hard work
➡ Here we use the “ask” pattern and futures in order
to produce an HTTP response
➡ There are other ways!
this?”
ou MOCK
ow do y
“But h
10. Creating Children:
➡ Direct use of context.actorOf is hard to stub/mock
➡ This is OK for simple children because Akka
TestKit is awesome
➡ But for more complex child hierarchies, it would
be nice if we could stub/mock child actors
11. Creating Children:
➡ Layer traits based on least required dependency
➡ ActorCreationSupport can be mixed with anything
➡ ActorContextCreationSupport requires context
12. Creating Children:
➡ Mix in a trait for creating children
➡ Override during testing
“
test the
How to
UTES?”
http RO
13. Creating Children:
➡ Put the routes in a separate Routes trait!
➡ Routes says: “I need an ExecutionContext!”
14. Creating Children:
➡ Layer traits based on least required dependency
➡ ActorCreationSupport can be mixed with anything
➡ ActorContextCreationSupport requires context
TestCreationSupport creates a FakeProcessJobActor
15. Creating Children:
➡ Mix in TestsCreationSupport into Routes trait
➡ Ready to stub!
“
cs2 tes
UDE, Spe
D
esome!”
ng is aw
ti
16. Initializing Actor State:
➡ Say an Actor uses a “Stuff” library
➡ Stuff needs some time to start…
“VARS
cess?”
c
rrent A
? Concu
17. Initializing Actor State:
➡ Initialize the actor using messages
➡ Only process messages once initialized
➡ Possibly stash messages away until ready
➡ Crash when initialization fails (parent handles failure)
18. Initialization using become:
➡ Allows you to build simple state machines
➡ Use multiple receive functions and switch behavior
➡ No need for vars!
19. Become is powerful sh*t:
➡ Allows you to build simple state machines
➡ Switch behaviour at runtime based on internal state
➡ Makes it possible to model processes and flows
20. Configuring Akka Apps:
➡ We all know hardcoding configuration is evil
➡ We don’t want to use a heavyweight DI
library for some simple settings
➡ How can we configure our Akka apps?
23. Using Settings:
➡ Access your Settings wherever you have a reference
to an ActorSystem or an ActorContext
24. Using Akka’s EventStream:
➡ How to communicate between disconnected actors?
➡ You don’t always have (or need) a reference to all
actors in the system who might care about your
messages
25. Using Akka’s EventStream:
➡ Publish messages on the Akka EventStream
➡ Anyone can subscribe to receive these
26. Using Akka’s EventStream:
➡ Messages that you have subscribed to are routed to
your receive method like any other actor messages
27. Using Akka’s EventStream:
➡ The EventStream is great for monitoring what
happens in your system
➡ You can use it to implement event stores and other
event-driven patterns
➡ It is also great for making your application easier to
test
28. Complex request/response
➡ So far we have used the “ask” pattern and futures to
do request/response with actors
➡ But what happens when the request handling flow
gets a bit more complex?
29. Complex request/response
➡ This might or might not be your cup of tea…
➡ There are other ways to model a sequential flow of
information…
30. Complex request/response
➡ We can use our old friend Become in a single-use actor
➡ We do need to make sure it gets killed after it is done
➡ We also need to take care of timeouts ourselves
