Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Akka in Practice: Designing Actor-based Applications

26,936 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

×