1

On SO there is a heavily-upvoted (albeit "closed") question entitled "Good use case for Akka" that I am looking for some further resolution on.

Although not the accepted answer, Akka's own Viktor Klang weighed in with a heavily-upvoted answer where he states that RESTful web services are a good use case for the actor-based framework.

But this seems to be in direct conflict with the most basic staple of Akka: Akka is for asynchronous systems, whereas REST services need to be synchronous, and are typically expected to produce results within 200ms (e.g., I shouldn't have to wait 6 seconds for a simple GET to return some JSON to me).

So I ask: how is Akka ideal for REST services if it is implicitly asynchronous and non-blocking, or is this just self-marketing hype?

Community
  • 1
  • 1
smeeb
  • 27,777
  • 57
  • 250
  • 447

1 Answers1

2

Why do you think that asynchronous means slow? :)

Of course because of the nature of HTTP protocol, from client point of view HTTP calls will be synchronous. But internally Akka will use its asynchronous capabilities to process requests as soon as possible.

spray.io is a standard Akka HTTP layer that will be replaced with Akka HTTP module soon (which is basically Spray 2.0). It's very lightweight and super fast.

And this is an example about how you can integrate synchronous HTTP and asynchronous Akka Actors. As you can see it creates Future and sends result back when it's done.

More advanced examples: http://techblog.net-a-porter.com/2013/12/ask-tell-and-per-request-actors/

sap1ens
  • 2,877
  • 1
  • 27
  • 30