Akka in Practice: Designing Actor-based Applications

18,987 views
19,305 views

Published on

Published in: Technology, Health & Medicine

Akka in Practice: Designing Actor-based Applications

  1. 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. 2. Agenda ➡ BOOTING UP ➡ THE RECEPTIONIST ➡ CREATING CHILDREN ➡ BECOME ➡ CONFIGURATION BY EXTENSION ➡ STREAMING EVENTS ➡ DOING REQUESTS/RESPONSE
  3. 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. 4. Booting Up: it is that easy :)
  5. 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. 6. The Receptionist: Spray exposes your entry-point actor to the outside world as an HTTP (REST) API
  7. 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. 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. 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. 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. 11. Creating Children: ➡ Layer traits based on least required dependency ➡ ActorCreationSupport can be mixed with anything ➡ ActorContextCreationSupport requires context
  12. 12. Creating Children: ➡ Mix in a trait for creating children ➡ Override during testing “ test the How to UTES?” http RO
  13. 13. Creating Children: ➡ Put the routes in a separate Routes trait! ➡ Routes says: “I need an ExecutionContext!”
  14. 14. Creating Children: ➡ Layer traits based on least required dependency ➡ ActorCreationSupport can be mixed with anything ➡ ActorContextCreationSupport requires context TestCreationSupport creates a FakeProcessJobActor
  15. 15. Creating Children: ➡ Mix in TestsCreationSupport into Routes trait ➡ Ready to stub! “ cs2 tes UDE, Spe D esome!” ng is aw ti
  16. 16. Initializing Actor State: ➡ Say an Actor uses a “Stuff” library ➡ Stuff needs some time to start… “VARS cess?” c rrent A ? Concu
  17. 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. 18. Initialization using become: ➡ Allows you to build simple state machines ➡ Use multiple receive functions and switch behavior ➡ No need for vars!
  19. 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. 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. 21. Configuring Akka Apps: ➡ Start by using the popular typesafe-config library
  22. 22. Configuration by Extension: ➡ Use the Akka extension mechanism to get a nice Akka “Singleton”
  23. 23. Using Settings: ➡ Access your Settings wherever you have a reference to an ActorSystem or an ActorContext
  24. 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. 25. Using Akka’s EventStream: ➡ Publish messages on the Akka EventStream ➡ Anyone can subscribe to receive these
  26. 26. Using Akka’s EventStream: ➡ Messages that you have subscribed to are routed to your receive method like any other actor messages
  27. 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. 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. 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. 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. 31. ot G QUESTIONS? away! ask
  32. 32. nt a W MORE? ises! exerc E do TH https://github.com/RayRoestenburg/scala-io-exercise-1
  33. 33. HAKKING! Happy manning.com/roestenburg !@rayroestenburg ✉ ray@scalapenos.com ✉ age@scalapenos.com !@agemooij

×