End-to-End Reactive Streaming RESTful service (a.k.a. Back-Pressure over HTTP)

5
votes

I have been trying to clarify this question online for a while without success, so I will try to ask it here.

I would like to find some resource or example where it shows how I can build an end-to-end fully back-pressured REST service + client. What I mean is that I would like to see that, given a REST client that implements Reactive Streams (whether in Akka, JS, or whatever), I will have (and be able to "visualise") the back-pressure handled throughout a REST server built, e.g. with Akka-Http.

To be clear, I am searching for something like the following talk (but I could not find slides or videos to confirm it): http://oredev.org/2014/sessions/reactive-streaming-restful-applications-with-akka-http

My doubts with most examples I see are about the fact that I can find plenty cases where the REST service (server) is using Akka Http and Akka streams for the back end, but I am not sure that the backpressure is "communicated" over HTTP and REST, if the client is implementing Reactive Streams. In such situation, would I have a single "stream" bridged over TCP/HTTP or just 2 independent streams? That is my main doubt and confusion.

Hopefully I was clear enough and someone will be able to shed some light on the matter.
In any case, thank you!

1
scalarestakkaakka-streamreactive-streams
Have you tried asking this question on the Akka Users Google groups page? You might have better luck there. – cmbaxter

1 Answers

11
votes

You’ve arrived in the right place to ask Akka questions :-)

There are two talks I’m aware of which show a demo how the backpressure mechanism really works when working with http.

1) One is Roland Kuhn’s talk on ScalaDays SF 2015: the backpressure over http demo starts around the 44th minute of this talk.

2) My talk from ScalarConf Warsaw 2015. the streams part begins around the 18 minute, and the backpressuring demo is seen around the 24th minute. It shows a “fast processing” and “slow processing” server, in which you can see the curl client being backpressured when the file is being uploaded (I use a file as an example because it’s a nice “big request”).

The back pressure is propagated to the client thanks to TCPs built in mechanisms for this - on the server side we simply do not read from the socket until demand is available, which causes the back pressure to be propagated properly.

I hope this helps!