Akka design patterns – Scala actors

Very interesting. I've built two sizable Akka projects for a client in the past month and I look forward to seeing what I could've done better. I think there's some refactoring in my future.

As for Akka itself, I'm very pleased with both its performance and the ease with which scalable, complex applications can be developed.

Coupled with the Play Framework the two open up some very interesting possibilities. For instance, one of the Akka systems I built recently handles caching for large datasets—a given cache can take 20-30 seconds to compute. Akka handles the computation while Play sits in front as a REST API. Requests come in for a dataset and the data is either returned from the cache or generated.

But if a request for a dataset comes in while the same dataset is already being computed, Play will return a Promise for the dataset already being cached. This didn't require any sort of lock system, I just put the AsyncResult[1] which will be fulfilled by an Akka future into Play's internal cache and return that. The future of a cached dataset will fulfill whatever incoming HTTP request is mapped to that AsyncResult.

[1] http://www.playframework.com/documentation/api/2.1.1/scala/i...

Have you experimented with typed channels (http://doc.akka.io/docs/akka/snapshot/scala/typed-channels.h...) at all? I've played around with them, and they seem to work pretty well, but don't seem to compose with the other "extensions" (e.g. the FSM one)

Bless you dude. You have no idea how this will change our lives!

Scala has been very interesting for me so far, but I've had limited know-hows on the best practices of doing certain things like using actors efficiently. Thank you so much.

And please complete the guide on authentication and authorization...It's by far one of the most important topics :)

I'm still reading through it, but it's very cool that you have a "lessons learnt" section in the github wiki.

Not sure if there is a connection, but I think that means "sister" in Singhalese