PRACTICEAKKA

Real World Application Design Patterns for the Intermediate Akka Developer

@agemooij!

@rayroestenburg!age@scalapenos.com✉ray@scalapenos.com✉

in

November 6th 2013

Agenda➡ BOOTING UP ➡ THE RECEPTIONIST ➡ CREATING CHILDREN ➡ BECOME ➡ CONFIGURATION BY EXTENSION ➡ STREAMING EVENTS ➡ DOING REQUESTS/RESPONSE

Booting Up:➡ How do we start up our Akka app? ➡ Where do we create the actor system?

Akka applications don’t need any containers!

“Why don’t we just write a main method?”

“Sure, why not?”

Booting Up: it is that easy :)

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 use a socket!”

Akka IO supports TCP, UDP, and HTTPWe will use Spray, a.k.a. akka-http

The Receptionist:Spray exposes your entry-point actor to the outside world as an HTTP (REST) API

The Receptionist:Your entry-point actor can use Spray’s routing DSL to handle requests

“But who is going to do the work?”

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

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!

“But how do you MOCK this?”

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

Creating Children:➡ Layer traits based on least required dependency ➡ ActorCreationSupport can be mixed with anything ➡ ActorContextCreationSupport requires context

Creating Children:➡ Mix in a trait for creating children ➡ Override during testing

“How to test the http ROUTES?”

Creating Children:➡ Put the routes in a separate Routes trait! ➡ Routes says: “I need an ExecutionContext!”

Creating Children:➡ Layer traits based on least required dependency ➡ ActorCreationSupport can be mixed with anything ➡ ActorContextCreationSupport requires context

TestCreationSupport creates a FakeProcessJobActor

Creating Children:➡ Mix in TestsCreationSupport into Routes trait ➡ Ready to stub!

“DUDE, Specs2 testing is awesome!”

Initializing Actor State:➡ Say an Actor uses a “Stuff” library ➡ Stuff needs some time to start…

“VARS? Concurrent Access?”

➡ Initialize the actor using messages ➡ Only process messages once initialized ➡ Possibly stash messages away until ready ➡ Crash when initialization fails (parent handles failure)

Initializing Actor State:

Initialization using become:➡ Allows you to build simple state machines ➡ Use multiple receive functions and switch behavior ➡ No need for vars!

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

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?

➡ Start by using the popular typesafe-config library

Configuring Akka Apps:

Configuration by Extension:➡ Use the Akka extension mechanism to get a nice

Akka “Singleton”

Using Settings:➡ Access your Settings wherever you have a reference

to an ActorSystem or an ActorContext

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

Using Akka’s EventStream:➡ Publish messages on the Akka EventStream ➡ Anyone can subscribe to receive these

Using Akka’s EventStream:➡ Messages that you have subscribed to are routed to

your receive method like any other actor messages

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

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?

Complex request/response➡ This might or might not be your cup of tea… ➡ There are other ways to model a sequential flow of

information…

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

QUESTIONSGot?

ask away!

MOREWant?

do THE exercises!

https://github.com/RayRoestenburg/scala-io-exercise-1

HAKKINGHappy

manning.com/roestenburg

!

@agemooij!

@rayroestenburg!age@scalapenos.com✉ray@scalapenos.com✉