Akka in Practice: Designing Actor-based Applications

  • 3,787 views
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

Views

Total Views
3,787
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
78
Comments
0
Likes
16

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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
  • 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