Play it or Spray it

Claudio Diniz
3 min readMar 7, 2016

--

I have seen lots of discussions about using Play Framework or Spray (now Akka-HTTP), to make REST APIs in Scala. I had to make the same decision two years ago and I chose Spray. But why? at the time, my main (probably immature) reasons were:

  • Play has lots of cool things and we can use it to make a REST API, but Spray is exactly a framework to make REST APIs
  • Spray “should” be faster since it’s more lightweight.

So, If someone asked me about my opinion on this subject, I always recommended Spray without any doubt!

I saw the same discussion again and again, and nowadays, I have another point of view. I have been working on both frameworks, and now it’s not easy for me to recommend one or another, because I think both options could result in an equally good project. Obviously, the choice depends on the team that will work with it and depends on the project features.

One of the main reasons to choose Akka-HTTP over Play could be performance (number of requests per second).

Since Play’s performance has improved in each new version, from version 2.4 to 2.5 the improvement “was almost 20%”, I decided to make a simple benchmark between Play and Akka-HTTP. I created an activator template project for Akka-HTTP and Slick 3.1 and I used it as test case. It has a simple supplier model, with a name and a description, and two routes, one for inserting suppliers and one to read a supplier by id. I implemented the same scenario in Play Framework 2.5 with play-slick (I ended up publishing a new template for Play 2.5 and slick 3.1, since there isn’t an updated template) and I tested the reading of a supplier with JMeter. I know that this is a simple test, but it is enough to make a comparison.

I found that Akka-HTTP is faster than Play, on average 6% faster.

Sincerely, I expected a bigger difference. So, is this difference in performance a reason to choose Akka-HTTP instead of Play? In my opinion, we cannot make a decision that will affect the whole life of a project just based on performance, even if the difference was bigger. I know that we cannot measure the performance of a framework just with one test scenario, but it gives me the idea that the performance could be very similar. Beyond performance, there are other things we should consider:

Team experience

For example, if all the projects that your company worked on were in Play framework, the cost and risk of beginning a new project in another framework would be very high.

Team motivation

If your team is eager to work on a specific framework, this will affect the productivity of the team, so we have to listen to the team’s motivation.

Project Features

For instance, what is the type of authentication to implement? Both frameworks support all kinds of authentication, but, maybe in Play, we have more options to do it.

Project Maintenance

Who will maintain the project? Is a Play project easier to maintain that an Akka-HTTP?

So, my conclusion is that there isn’t an obvious answer to the question. I’ll evaluate all mentioned points in my next project to make the best decision and you could do it as well!

--

--

Claudio Diniz

Software Engineer and Agile Enthusiast @ Work, Photographer, reader, runner and a wannabe healthy | Flickr https://goo.gl/SVVEiV| LinkedIn https://goo.gl/39bjte