Tuesday, January 22, 2013

Spray.io Stack or Play Framework

So I've decided on Spray.io for my new RESTful project. It took some time to decide which Scala framework to use but after a thorough look at the various frameworks I've decided that Spray.io would be the most ideal one for the project I'm taking on. I think either one would have been a good choice but at the end my decision was based on simplicity, readability and relevance. I don't think one can go wrong with either but it does come down to a personal taste really. It was a hard decision considering how much support Play has and that is not to mention the backing of Typesafe, but the community and adoption is also important which Spray.io is in no way lacking.

To understand why I decided on Spray.io I should first explain roughly the requirements for the project. I'm going to build a RESTful based application which I can use the REST api to build web apps, mobile apps aswell as providing the API for third parties to use. Therefore it's an API first application, this being a crucial part I needed something light weight which will allow me to grow when required. Scalability is important as I want to keep it very light to begin with and scale up again when required. Securing the API by the use of Authentication and Authorization is also a priority and coming from a Spring background it is hard to beat what Spring Security can do for your application. I have used Spring Security since the early days before it was part of the Spring Framework (aka Acegi Security).

I chose Scala as I've always wanted to get into it, I wanted the flexibility that the language provides but with the type safety that Java has. I also wanted to have access to the Java API as well as direct access to Java based libraries, this is very important to me because of the nature of the project. But this post isn't about why I chose Scala but rather why I chose Spray.io.

I have looked at all the frameworks in the Scala eco system, some more thoroughly than others, but my decision drilled down to two, Play framework or Spray.io (not a framework :-) Play was quite easy to get into, the command line interface was very similar to Grails and Ruby on Rails, so it's a very pleasant environment to build a web app in Scala. But that was the difference there, I am not building a web app but rather a RESTful API. I did my research and found that I could build my RESTful app using Play and use only what I needed, however, I quickly found that the framework was very heavily targeted towards a web application. I did look at Play mini but I only looked at it after I played around with Spray.io and by then my preference rested more towards Spary.io.

Play, however, met all my demands in one way or another but maybe it was too heavy or maybe my ego required a bit more of a challenge that made me look further into Spray.io. Play is based on Netty whereas Spray.io uses spray-can (can also use Jetty) which offers the same asynchronous performance (using Akka.) Play uses Akka and allows a developer to make use of Akka actors as does Spray.io, however, Spray.io seems to provide a better integration there than Play does, but with very minimal differences. Play offers a DIY method of security as does Spray.io, however, there is a third party module (Secure Social) that provides everything one needs in terms of security for the Play framework. Having said that, Spray.io has a nice integrated approach to authentication and authorization by using the relevant directives.

As mentioned already, Play has the backing of Typesafe which is a huge plus when it comes to the survival of a framework or a given tool suite. However, from my investigations Spray.io has been adopted by various global companies and with the outstanding active and helpful community I know Spray.io will be around longer than web 2.0, 3.0 or even n.0.

What it comes down to is that Play is a framework (if you had not noticed so far in my post) and Spray.io is a suite of libraries that do what is required of them for the purpose their meant for, and try their best to stay out of your core application.

Additionally, with Spray.io I feel I'll be able to get more of an understanding as to how Akka and even how SBT work considering that this my first Scala based application, but more importantly build beautiful RESTful API's. I say this because the more I've used Spray.io the more I've fallen in love with the clean, concise and readable approach to the implementation of my application. I'm able to also keep my project light weight and clean from all the bells and whistles that a typical web framework provides, this is very important considering that I'll be using a Javascript/HTML based framework for building the web application UI and a mobile framework for the mobile UI, both using the same RESTful API's.

I plan to deploy the application to Cloud Foundry and Play was the best choice there, but I found that I can deploy my Spray.io application as a standalone application so that isn't going to be an issue. But the first class support for Play both on Cloud Foundry and Heroku is a huge plus for anyone using Play.

If I get time I will put up some code examples of the Spray.io REST implementation but for now here are some useful links for anyone interested:
http://www.cakesolutions.net/teamblogs/2012/07/29/api-first-rest-in-akka-and-spray/
http://skillsmatter.com/podcast/scala/spray-rest-on-akka
http://marakana.com/s/post/1150/spray_rest_on_akka_from_the_northeast_scala_symposium
http://www.decodified.com/spray/2011/03/31/introducing-the-spray-framework.html

Here are two links for cloud foundry:
http://blog.cloudfoundry.com/2012/05/11/running-standalone-web-applications-on-cloud-foundry/
https://github.com/cloudfoundry-samples/spray-can-server
http://docs.cloudfoundry.com/frameworks/play/java-mongodb.html


Scala/Spray.io with MongoDB:
Casbah - https://github.com/mongodb/casbah
JanxSpirit g8 template - https://github.com/JanxSpirit/spray-mongodb.g8
Salat - https://github.com/novus/salat

12 comments:

  1. Replies
    1. Best place to start is the wiki page on github: https://github.com/spray/spray/wiki/Authentication-Authorization

      It's a little outdated (atleast when I was reading through it) but it's a great place to start.

      I'm planning to write up a post demonstrating how to secure a Spray.io api using the security directives that come with the suite. But I've been a little busy recently with work, ironically working on a project using a Play+Akka+Mongo stack. However, it has helped confirm my concerns and reasons for choosing Spray.io over Play for a RESTful api.

      Delete
  2. Hi, Thanks for posting your thoughts and it's really helpful. Can you help me by pointing to some example with spray and mongo integration ??

    ReplyDelete
    Replies
    1. Thanks Giri, my pleasure, nice to see this post has helped others. I know it helped me by just writing this post.

      For scala mongo integration you should look into the Scala mongodb driver 'Casbah' which is basically a wrapper around the Java driver. A good spray.io reference would be the JanxSpirit g8 template.

      Also for further integration between your Scala objects and the collections in MongoDB you might want to look at Salat.

      Links:
      Casbah - https://github.com/mongodb/casbah
      JanxSpirit g8 template - https://github.com/JanxSpirit/spray-mongodb.g8
      Salat - https://github.com/novus/salat

      Hope that helps...

      Delete
    2. I think a better fit for integrating MongoDB with any Akka-based system is ReactiveMongo (http://reactivemongo.org/) which is an async scala driver written by Play! folks (depends on Play iteratee library). It is awesome to have non-blocking database IO.

      I've been working on a Spray-based framework project called Sprest in my spare time that includes an example app for integrating with MongoDB using ReactiveMongo. Check it out here: https://github.com/markschaake/sprest

      Delete
    3. Thanks Mark, that is awesome! Thanks for pointing it out. Good stuff on your example/template app too, will check it out when I get a chance.

      Delete
  3. Hello, it was nice to post your thoughts on spray and play. Regarding the deployment I find spray more flexible. You can either deploy it as a stand-alone application or as a war file. Cloud foundry has an example with spray:
    http://blog.cloudfoundry.com/2012/05/11/running-standalone-web-applications-on-cloud-foundry/

    ReplyDelete
    Replies
    1. Ni Nikolas, sorry for the late reply, slipped my mind. That is a nice option but I would prefer to see PaaS environments like Cloud Foundry and Heroku officially supporting spray-can deployments.

      For now you can look at the following example apps on github to help you deploy your spray-can application on either heroku or cloudfoundry:

      * https://github.com/ontoadaptive/spray-template-heroku
      * https://github.com/cloudfoundry-samples/spray-can-server

      And there is also this outdated thread that I had bookmarked awhile ago:
      https://groups.google.com/forum/?fromgroups=#!topic/spray-user/t260jD1c1aA
      With the corresponding issue raised for it:
      https://github.com/spray/spray/issues/74

      Delete
  4. As I understand Play will be switching to Spray as soon as Spray ready for it. Eventually everything will go to Scala, if speaking about TypeSafe stack. I mean it is natural to have Scala server under the hood not Java one (netty). But probably Play user will not feel it too much. So, if one goes Play way it will be on right way.. anyway :)

    ReplyDelete
    Replies
    1. That sounds interesting, do you have any links to any discussions or posts regarding that? I presume you're talking about spray-can? I think using spray-can with Play is possible, but whether Play! will move to that officially or not would be interesting to see.

      I'm currently using Play at work and Spray on my personal project. I think there are other factors for using Spray. For example one of the things I like about using the Spray.io stack is the spray-routing module (scala based) DSL for writing API's, just feels more natural to me for configuring my RESTful api's when compared to the Play approach. Bare in mind that Spray.io is a stack of libraries and not a web framework as such, so technically speaking you can use what you want or even use with other frameworks (though I've never tried or needed to... yet)

      Delete
  5. Really worth to read all info, thanks allot.

    ReplyDelete
  6. It’s an awesome and incredible article in support of all the web visitors; they will take advantage from it I am sure. I am truly grateful to the holder of this site who has shared this great piece of writing at at this time.

    The Podiatry Websites Examples - Custom websites solutions by Optimized360.

    ReplyDelete