3 ms·
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 ri
by oacgnol 14y ago
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 14y agoInternally, 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 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 14y agoThat'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.