

Smoke: Simple, asynchronous scala HTTP powered by Akka - anorwell
https://github.com/mDialog/smoke

======
noelwelsh
I don't understand why this exists. Between BlueEyes, Spray, Unfiltered,
Finagle, and probably others I have forgotten, I don't see the need for yet
another asynch HTTP library.

~~~
chrisdinn
All great libraries, all a little different from each other. Scala provides a
lot of flexibility for designing solutions. On top of that it's a relatively
new language with new open source projects appearing all the time, changing
the landscape at an impressive rate. For instance, Smoke is built entirely on
top of Akka 2.0, which was only released a few months ago but is an impressive
step forward for parallelism on the JVM.

Combine Scala's flexibility with the importance of HTTP to so many of us, I'm
not surprised (nor disappointed) to see a lot of variety in this space. I hope
we'll see even more of them as the language matures.

We didn't see any of those libraries as an ideal solution to our problem so we
built our own. If this solves a problem for you as well, I'd be happy to hear
that. If not, I'd love to hear how you think it could be improved.

~~~
noelwelsh
Well, I prefer a different mechanism for error handling. If you scroll down to
"Error Handling" at <http://noelwelsh.com/blueeyes/concurrency.html> you'll
see my solution and justification for it. (FWIW, BlueEyes is based on Akka
2.0's Futures as well.)

~~~
chrisdinn
Thanks for the link, that was a good read.

Sounds like the concern is that when an error is raised inside an actor, the
error is swallowed by that actor's thread. If you were waiting for it to
respond you're end up with a mysterious timeout error and no idea where it
came from. That's a good issue, one I definitely struggled with.

Internally, we're addressing this problem by building our actors in such a way
that they return a Status.Failure when an error is raised, using unit tests to
ensure a response is always sent even when an error occurs. Typically, our
responder functions are built from a number of Futures composed using the
tools provided by Akka. This works well in some cases, when an error is raised
early in a function composed from many Futures it gets passed right to the
OnError handler to return an appropriate response. In the case where you get a
mysterious timeout it can definitely make debugging difficult. Akka's
excellent logging has saved us there many times.

The goal was to lean on Akka whenever possible, adding elements to the Smoke
DSL only when absolutely necessary. We've been able to make this work in some
pretty non-trivial applications. Will that work for everyone? Hard to say.
Your mileage may vary.

------
oacgnol
This looks cool. What's the use-case for it versus using something like Play!
2.0 + Akka for async HTTP?

As far as my limited knowledge of Play (learning it right now, so I could be
far off), Play can do async HTTP and already makes use of internal Akka actors
for handling requests.

~~~
chrisdinn
Internally, we wanted a way to build and deploy HTTP services quickly and
easily. We wanted them to be asynchronous and we wanted a DSL that developers
familiar with HTTP would pick up on quickly, without a lot of additional
research. We've been having a lot of success with the composable Futures in
Akka 2.0 and wanted to set developers up to leverage the full power of the
Akka toolkit (and boy, is it powerful).

It's much lighter weight than play2 or play2-mini
(<https://github.com/typesafehub/play2-mini> built on top of play2). , but
does provide some similar functionality. There's definitely a whole lot less
code in Smoke. That may be a good thing or a bad thing, depending on your
perspective.

~~~
oacgnol
That's awesome, I was planning on using Play 2 to build a purely RESTful
service for a weekend project but I wasn't aware of either Smoke or
play2-mini. I'll be looking into the three of them now to see which one I
would use.

Personally, I'm not too concerned about the amount of code as Scala tends to
be terse by nature. A creeping problem from what I've experienced with Scala
libraries is trying to be waaay too cute with DSLs and syntax. But as long as
the source code and DSL is easily read and traceable, I'm happy.

------
jzoidberg
How does this differ from Spray?

<https://github.com/spray/spray>

~~~
chrisdinn
Spray is a great library. It's full featured, with it's own Akka-based HTTP
server and a full client lib.

Smoke is a smaller, more focused tool. You will find a lot of things Spray
does that Smoke does not. Smoke has a significantly different DSL, relying on
Akka's composable Futures to take care of things like error handling.

Smoke evolved through an attempt to build the simplest possible asynchronous
HTTP services on top of Akka, without sacrificing any of the key features we
needed to deploy those services at scale.

The goal of Smoke is not so much to compete with Spray as it is to provide an
HTTP-service-focused alternative to Finagle
(<https://github.com/twitter/finagle>) that uses Akka Futures instead of
Twitter Futures, and includes everything we needed to build, test and deploy
those services quickly.

So far, it's been working quite well for us.

~~~
jzoidberg
Awesome - thank you. It is great to have so many choices

------
whalesalad
The acronyms in the web-dev scene are going to become self aware soon and
start running the world.

~~~
scottostler
By this point, isn't HTTP a pretty standard acronym in the web-dev scene? :)

------
dkhenry
so the real question . How does it compare to flask ?

