Web development frameworks – part 2 : Play Framework 2.0

The tutorial and reference documentation used for this article is all available from the Play documentation site.

The first part of the article will go over the set of tasks we proposed to do with each framework, then moving on to evaluate each criteria item.

Install the framework in a development workstation

Extremely simple, three steps:

1. Download the ZIP distribution
2. Unzip it
3. Add the unzipped folder to your PATH

And it’s good to go!

Setup a development environment using a free IDE, application server and database

Nothing to do here. The framework provides an internal application server for development and you can work with the internal database both in memory or file system based flavours.

As far as IDE support goes, you can use your favourite text editor or a full blown Java IDE such as Netbeans and Eclipse. Since Play reloads all resources on the fly as you modify them, you don’t really need any fancy IDE integration.

It’s worth noting though, that the framework provides extended support for Eclipse and IntelliJ, in terms of built-in actions, shortcuts, autocomplete, etc. So you might want to use one of those two if you are already familiar with them.

Develop the “Hello world” or similar sample outlined by the frameworks tutorial

The framework’s tutorial proposes the development of a To-Do list application. Going from scratch to a working “hello world” status is completely trivial and really fast (minutes). And moving forward from that to a fully working app feels natural and easy to understand.

Modify the sample app to perform a specific database query over a custom structure and display the results

Play 2.0 uses the EBean library as default data access layer, it’s quite easy to use and understand. The use of custom SQL queries is supported out of the box by the framework and there is no mystery to it, it’s similar to JPA native queries and doesn’t require any major hassle to use.

Add a dependency to a third party library and perform a computation using it in our app

Play 2.0 has both the option to add a JAR file directly to the project (copying it to the /lib project folder), or to add a dependency through it’s built-in dependency system (using Apache Ivy via SBT).

To push it a little I decided to add a Maven central repo reference and use the library. It proved straightforward, just add a line to the Build.scala file and if needed you can even add your own repository in the same file.

As a sidenote, you need to rebuild your app dependencies after changing stuff like this or it won’t compile.

Develop a “Hello world” REST service

Publishing a JSON REST service is quite simple, the documentation is clear and to the point. The only complaint is that it’s not explicit on this documentation page what imports are needed (I had to loose two precious minutes of my life browsing the API to find them :P).

Play provides all the tools you need to encode/decode JSON and XML quite easily, and the built-in routing mechanism makes it simple to map all HTTP methods to specific controller Java/Scala methods.

Consume our own service from our app

Play provides a built-in library to consume web services. Handling of JSON and XML responses is simple and easy.

Calls are made asynchronously and handled via Promises (a structure similar to Java’s Futures), which makes them quite powerful in terms of how you can handle them within the flow of your app.

On the other hand, the code to invoke a simple REST GET service seems a little bigger/more complex than it needs to be. I would appreciate it if shortcuts were provided in the API for simple (ie. blocking calls) use cases while still supporting the full async power for the developers who need/want it.

Evaluation

Ok, lets pass veredict! This is our evaluation based on the items described above:

Learning curve: GOOD

If you are a Java developer (I infer it’s the same for Scala skilled devs) it’s really, really simple to get going with Play. It took me less than a day’s work to feel at home with the framework, and all my Java skills felt like still available and empowering what I was doing.

It should also feel very familiar to developers that often use RoR, Django and similar frameworks, since the structure of projects and command line usage is very similar.

Development performance for simple tasks: GOOD

It’s a breeze to code the usual stuff. And the capability to change a file and just refresh your browser to see the changes will seem like a miracle to Java web developers.

Development performance for complex/singular tasks: GOOD

The structure of the projects and transparent integration with Maven makes it really simple to include third party Java libraries or to add completely custom built classes to perform specific computations. In short, all you can do in any Java framework you can do in a Play project, in the worst case you just code plain old Java and it will work just fine.

Dependency management: GOOD

Maven integration works fine and is easy to use, you can connect your Play projects to existing corporate Maven repositories and re-use all the major Maven public repositories.

Code performance/security tuning capabilities: MEDIUM

Regarding performance tuning, on the back-end side you can basically do everything you can do on any other Java based framework. You can customize and tweak your code as much as you want, using the frameworks built-in APIs or not.

In the security front I miss the posibility to write a Servlet Filter to manage injections and XSS generically, but you can manage to develop your own XSS and CSRF prevention components quite easily.

Version 2 of the framework still lacks built-in mechanisms against common attacks though, which in my opinion should be provided out-of-the-box. The developers seem to be working on it though.

Platform escalation/redundancy capabilities: BAD

It runs on a JVM, so it leverages all it’s corporate goodies. But at this moment (versions 2.0.x) there is no way to deploy a Play 2 app as a WAR file to regular application servers.

This is a big problem in my opinion, since using a robust and proven application server for corporate and/or mission critical systems is a must in my book, and the built-in play server is nice, but I woulnd’t sleep too sound with a big app deployed on it in a production environment.

The Play team is working on solving the WAR deployment compatibility and the feature is tagged for version 2.1, so it shouldn’t be long before this is solved.

Acceptance in corporate markets: MEDIUM

Java is stablished, accepted and proven, so the platform itself is almost always not a problem. The big thing here is the same as the previous item, at this moment you can not deploy a Play 2 app in other application servers, and most companies IT departments have already chosen their application servers and they are not Play 2.

Hopefully when version 2.1 comes along this issue will be gone.

Complexity of developing and consuming SOAP and REST services: GOOD

The bundled WS API is straightforward and easy to learn, and it gets the job done. It could be a little simpler for simple scenarios, but it’s not a big deal.

TL;DR

Play Framework 2 is an excellent choice for every type of web based development, specially for developers already skilled in Java or Scala. It’s easy to learn, a breeze to use and leverages all the power of the JVM and the huge ecosystem of available Java libraries.

The latest iteration of the project (v2.0) lacks the possibility of packaging your apps as regular Java WAR files and deploy them to other application servers. This is a big problem, specially for corporate environments, because most organizations already have a stablished selection of application servers. The Play team is working on adding this feature for v2.1, we await eagerly.

On my next post I’ll review Ruby on Rails, I know it’s not news to anyone, but I think using the same evaluation process on all our options will light the way.

Reference: Web development frameworks – part 2 : Play Framework 2.0 from our JCG partner Ricardo Zuasti at the Ricardo Zuasti’s blog blog.