Exploring Akka-HTTP in Scala (1)

Several months ago, while playing with Scala, I've experimented with Spray. As new needs for a production system have recently come up, I am looking at the natural descendent of Spray: Akka-HTTP.

The Akka-HTTP modules implement a full server- and client-side HTTP stack on top of akka-actors and akka-streams. It's not a web-framework but rather a more general toolkit for providing and consuming HTTP-based services. While interaction with a browser is of course also in scope it is not the primary focus of Akka HTTP.
From: Akka-HTTP

The simple need for a HTTP-service provider brought me to explore more of the interesting Akka ecosystem. In fact, Akka-HTTP promotes an interesting way of providing and consuming HTTP-based services and it is built on top of akka-actors and akka-streams.

Akka-actor system

Akka-actor implements the Actor Model to provide a better platform to build scalable, resilient and responsive applications.
From: What is Akka

Check out the following slides and see also the Reactive Manifesto and the Reactive Manifesto 2.0.

Introducing Akka from Jonas Bonér

Akka-streams

Akka-streams is an abstraction over the Actor system that simplify streams usage, for instance, by taking care of managing back-pressure.
From: Streams introduction

As Endre Varga put it in a very nice blog post (with simple and effective examples):

The primary goal of streams is to provide a simple way to:

• build concurrent and memory bounded computations
• that can safely interact with various forms of non-blocking IO interfaces
• without involving blocking
• while embracing multi-core concurrency,
• and solving the typical pitfall of missing back-pressure: faster producers overwhelm slower consumers that run on a separate thread, resulting in OutOfMemoryExceptions.

From: Threading & Concurrency in Akka Streams Explained (part I)

In the same post, Endre summarizes the properties of streams as:

• Streams do not run on the caller thread. Instead, they run on a different thread in the background, without blocking the caller. 
• Stream stages usually share the same thread unless they are explicitly demarcated from each other by an asynchronous boundary (which can be added by calling .async between the stages we want to separate). 
• Stages demarcated by asynchronous boundaries might run concurrently with each other. 
• Stages do not run on a dedicated thread, but they borrow one from a common pool for a short period.

Here is another good Akka-streams 101 and a presentation:

Reactive Stream Processing with Akka Streams from Konrad Malawski

Read about the more general initiative of Reactive Streams to provide a standard for asynchronous stream processing with non-blocking back pressure here. And see the following presentation: