Web Development Frameworks: Play Framework 2.0
Web Development Frameworks: Play Framework 2.0
Join the DZone community and get the full member experience.Join For Free
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:
- Download the ZIP distribution
- Unzip it
- 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.
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.
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.
Published at DZone with permission of Ricardo Zuasti , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.