Akka HTTP vs Other REST API Tools

Table of contents

Reading Time: 3 minutes

Hi Folks !

Lately there have been a lot of tools that allow us to build rest APIs like the following :

Akka Http
Play
Scalatra
http4s
Finch
Spray

In my blog today, I will be discussing Akka Http and its counterparts(competitors) in terms of their advantages, disadvantages, performance and use cases.

Let us begin comparsion of Akka-Http with Scalatra.

Scalatra is a thread based,it works by handling servlets and requires servlet container like jetty to run, it can delegate work to akka as per its documentation.On the other hand akka-http is actor per request, and it doesn’t require a container and writing actor model code is more natural pattern. In terms of DSL, Both have comparably easy and well written DSLs for writing routes.

Comparing in terms of performance it has been noted and well established in practise that akka-http application behaves much better than scalatra and continue to operate well while getting bigger traffic. The efficient performance of Akka-http vs Scalatra is largely because of the following :

Akka-Http has better default configurations i.e. thread pool size etc for optimal performance.
Akka-Http integrates seamlessly well with slick.
Akka-Http allows database connection pool to expand and scale out more efficiently for better throughput.

Moving ahead in the list let us discuss about Spray
Informally one can say the spray was the one that worked in akka style to build api’s as it was heavily dependent on the implementation of Akka Actors and its ecosystem.
Spray was vastly popular before the Akka team captured on the idea that its performance could be further enhanced and optimised by amalgamating akka streams with akka actors.

So after Akka 2.4 , support for Spray was withdrawn and developers were forced to migrate to Akka-Http in order to utilise other powerful libraries of Akka like Akka Persitence.
The above aptly explains the performance of Akka-http over spray to have brought closure over Spray support.

Going Ahead let us discuss why I would still prefer Akka-Http over http4s.
Seeing the implementation and structure http4s is very well architected, very principled, and very easy to understand, but only if one is acquainted with the scalaz ecosystem. But the major bottleneck lies in the fact that it has absolutely poor and improper documentation that requires hell lot of a work to be able to match Akka-http Documentation.

Another small competitor to follow is Finch. Having a backing of a big name like Twitter, Finch seems to be quiet old and the fact of the matter is that Twitter wrote alternatives for it long back. No doubt the great thing about Finch is that you get all the benefits of Finagle and finagle-http, which have years of battle-testing in many demanding environments but the learning curve is extremely steep and the you may run into intimidating compiler errors.

Not to demotivate you further another aspect of Finch is, with Finch you are dragging the entire Twitter ecosystem into your application. Now this may be good or bad, but it all depends whether you want to deploy the application with the Twitter Server and use all of their monitoring and use finagle for RPC between services.

Having discussed a couple of Akka-Http counterparts, let us talk about Play.
For the majority of Scala lovers, the best way is the Play Framework. It’s stable, very well designed, extremely well documented. So if you have UI in use , Play is a good choice.
But if you don’t need to have a UI probably going with Akka-HTTP is the best choice.

Having said all that the blog shall remain incomplete if I don’t elaborate on why I would go with akka-http over all its counterparts.

Akka.Http has build in server side and client side libraries. It also supports for standard serialisation such as JSON/XML and the we have the option to our own serialisation too.
It has a fairly skillful routing DSL which is pretty declarative and easy.
Akka.http provides seamless JSON support using this library akka-http-spray-json.
Unlike Play it is not a full stack web framework.
Like Scalatra it does not require a Container.
Reactive and message driven.
Multiple levels of APIs available to allow flexibility and ease of development and more options.
Highly scalable, maximum throughput and minimum latency.

Happy Reading !

References