At Skiddoo, we use the Play Framework for our REST API. Before building it, no one in the team had worked with this framework previously. But the reactive and stateless orientation of the framework made us believe it was the best choice if we wanted to build a lightweight and scalable application. Because we all come from a Java background, we choose naturally the Java version of the framework.
I could say a lots of good things about Play (JSON as first class citizen, asynchronous I/O..) and some annoying things too, but today is about Akka. So why am I talking about Play ? Because Play has been built on top of Akka (and other technologies). That makes Akka a potential first class citizen for every application using Play.
Until recently, we were only using Akka for its scheduler:
It was a solution for us to schedule some background tasks to be run repeatedly at a particular frequency (some of those tasks should have probably been a different independent service, but that’s another story).
And recently, we decided our API was doing too many things, it was time to refactor some services and pull them out of the Play application. As a start, we pulled out our tracking system (track all the flight searches made through our API to provide statistics to other teams, marketing for example).
I will assume you’ve heard a little bit about Akka and you have a global idea what it is about. My main goal was a service I could start/stop without impacting the other services communicating with it, and without losing any information.