Akka in Practice: Designing Actor-based Applications

Uploaded on


  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads


Total Views
On Slideshare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 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
  • 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
  • 4. Booting Up: it is that easy :)
  • 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
  • 6. The Receptionist: Spray exposes your entry-point actor to the outside world as an HTTP (REST) API
  • 7. The Receptionist: Your entry-point actor can use Spray’s routing DSL to handle requests ork?” o the w “But ing to d ho is go w
  • 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?
  • 21. Configuring Akka Apps: ➡ Start by using the popular typesafe-config library
  • 22. Configuration by Extension: ➡ Use the Akka extension mechanism to get a nice Akka “Singleton”
  • 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
  • 31. ot G QUESTIONS? away! ask
  • 32. nt a W MORE? ises! exerc E do TH https://github.com/RayRoestenburg/scala-io-exercise-1
  • 33. HAKKING! Happy manning.com/roestenburg !@rayroestenburg ✉ ray@scalapenos.com ✉ age@scalapenos.com !@agemooij