As I have a few minutes to spare I thought I would write a piece about my experiences with the Play Framework version 2.
For those of you who don’t know what the Play Framework is, where have you been? Originally based on the RoR paradigm, Play Framework offers a flexible REST based web development environment for Java and Scala.
- Scala(or Java)
- Flexible data persistence
- Hot reloading
- Dependency management(SBT)
- Debug mode
- Scala console
- Akka integration
- Memcache based caching layer
- Clunky templating
- No easy way of overriding the routing(I’ll explain later)
- Deployment to production
So there is a brief list of things that spring to mind, I think I explain by working backwards through them.
SBT, where to start with SBT? Its an acronym for Simple Build Tool, which is a blatant lie. If you want to understand SBT configuration files, you need a PHD. For example syntax like += and := are hardly the easiest to decipher for someone new to the framework. I appreciate its going for minimalism unlike the ANT and Maven rather verbose file formats, but at the same time the learning curve for SBT is quite a bit higher, give me Maven any day of the week.
Deployment to production: this I can’t really blame on Play Framework since its ahead of its time, but it does make life harder. Play Framework 1.x used to be easy to create a WAR file and deploy it to your favourite servlet container, 2.0 makes use of non blocking IO and websockets for some communication and the old servlet container spec to 3.0 does not support these standards. There is a WAR file plugin that will generate a WAR for you, but if some stuff doesn’t work, whats the point? Similarly, Apache HTTPD does not support websockets, so if you are wanting to use a proxy to deploy your application, you are forced to use Nginx or similar.
Clunky templating: Play framework version 1.x used to make use of Groovy when creating its templates, you passed in variables and the templating engine could turn these variables into HTML blobs at render time. It worked quite well, but it wasn’t typesafe. Developer X would change backend code Y, but not update template Z and boom, you deployed to production only to find it not working. In Play Framework version 2.x they have overcome this and other issues by using Scala based templates, backing classes are generated at compile time to pass in the require objects and so typesafety is ensured. But, its a pain in the ass, getting the server happy with the imports, the parameters declared at the top of the template etc is a never ending cycle of trial and error, and one day it will work, another day not. I know a lot of this is to do with it being in dev mode and trying to construct these classes on the fly, but its a pain. Also you make one small change to any part of the View and the class needs recompiling and reloading which is time consuming.
So with those gripes out of the way whats good about Play Framework version 2.x?
Memcache caching, out of the box, with no extra effort, allows you to utilise a proper caching mechanism for your application and on top of that, because of how memcache distributes, if you use a clustered setup, you can easily add another node and everyone have a copy of the same cache.
Akka integration: I had issues getting my head around Akka at first, so much so I went and bought a book about it. But Akka is great, it allows you to create distributed job management clusters with minimal effort. Once you have an understanding of the code and how to pass the objects around, creating complex Akka jobs to manage nodes and clusters became pretty trivial. The only downside being the out of the box scheduler didn’t allow Cron style schedules for jobs so I found a 3rd party library to allow me to do that using the Quartz scheduler.
For those of us new to Scala the console mode is very useful to test out syntax and Scala functions, and its quick and easy to get to with Play:
And you are in.
Debug mode: rather than remembering those CATALINA_OUT options to get the JVM listening for a debugger, play debug, and all you have to do is connect your favourite IDE and debug away.
Dependency management, of course whilst SBT is annoying, having a dependency management framework setup for you and running out of the box on a new project is always nice.
Plugins, a mainstay of Play Framework version 1 and not gone away in version 2, plugins provide a great way to get additional functionality with minimal effort, add a dependency to SBT and install the plugin, as simple as that, SecureSocial is a great authentication tool.
In version one when it came to data persistance you really only had once answer: JDBC and SQL data stores. In version 2 they have really gone for ultimate flexibility, and it has really paid off I chose to use Squeryl as my JDBC driver, but that is by no means the (A)norm (sorry terrible joke), anyway there is nothing stopping you using a NOSQL data store and I would be sorely tempted to try out MongoDB on my next project as a Play Framework backing store as its document storage engine, lends itself to just this sort of scenario.
Now my final Pro, Scala. When I started using Play Framework 2.x I was a Java man, whilst I have used other languages over the years, my predominant language is Java. But not to shy away from a challenge and acknowledging that Play whilst it supports Java is mostly written in Scala, I decided to completely rewrite Meteorite Cloud in Scala to conform, and that is by far the best decision I have made on this project. The amount of lines of code I managed to throw away by Scala’s concise nature and syntax was amazing. Whilst I still use Java on a daily basis, the fact Scala is so easily used along side Java classes will make me really consider it every time I start a new project.
So there we go, my overview of Play Framework 2.x, feel free to leave a comment or two if you agree, disagree or think I’ve missed something.