Lately, there have been a lot of tools that allow us to build REST APIs, like Akka HTTP, Play, Scalatra, http4s, Finch, and Spray. In my blog today, I will be discussing Akka HTTP and its competitors in terms of their advantages, disadvantages, performance, and use cases.
Akka HTTP vs. Scalatra
Let us begin the comparison of Akka HTTP with Scalatra. Scalatra is thread-based; it works by handling servlets and requires a 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, it doesn’t require a container and writing actor model code is a more natural pattern. In terms of DSL, both have comparably easy and well written DSLs for writing routes.
In terms of performance, it has been noted and well established in practice that an Akka HTTP application behaves much better than Scalatra and continues to operate well while getting more traffic. The efficient performance of Akka HTTP versus Scalatra is largely because of the following:
- Akka HTTP has better default configurations, like thread pool size, for optimal performance.
- Akka HTTP integrates seamlessly well with Slick.
- Akka HTTP allows the database connection pool to expand and scale out more efficiently for better throughput.
Akka HTTP vs. Spray
Moving ahead in the list, let us discuss Spray. Informally, one can say that Spray was the one that worked in Akka style to build APIs, as it was heavily dependent on the implementation of Akka Actors and its ecosystem. Spray was vastly popular before the Akka team captured the idea that its performance could be further enhanced and optimized by amalgamating Akka streams with Akka Actors.
After Akka 2.4, support for Spray was withdrawn and developers were forced to migrate to Akka HTTP in order to utilize other powerful Akka libraries, like Akka Persistence.
Akka HTTP vs. http4s
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 a hell of a lot of a work to be able to match Akka HTTP documentation.
Akka HTTP vs. Finch
Another small competitor is Finch. Despite having the backing of a big name like Twitter, Finch seems to be quite old, and the fact of the matter is that Twitter wrote alternatives for it a long way 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 you may run into intimidating compiler errors.
Not to demotivate you further, another aspect of Finch is that 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.
Akka HTTP vs. Play
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, and 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, going with Akka HTTP is the best choice.
Having said all that, this blog shall remain incomplete if I don't elaborate on why I would go with Akka HTTP over all its counterparts.
- Akka HTTP has built-in server side and client side libraries. It also supports standard serialization, such as JSON/XML, and we have the option of our own serialization, too.
- It has a fairly skillful routing DSL, which is pretty declarative and easy.
- Akka HTTP provides seamless JSON support using the akka-http-spray-json library.
- Unlike Play, it is not a full stack web framework.
- Like Scalatra, it does not require a container.
- It is reactive and message-driven.
- It has multiple levels of APIs available to allow flexibility and ease of development.
- It is highly scalable, with maximum throughput and minimum latency.