PLAY Framework Observations

Going into James Ward’s talk on the PLAY framework I had no hands-on experience with the framework. I only knew of it from the odd mention in other developers’ Facebook updates.


  1. A light-weight web application framework with its own integrated web server (Netty).
  2. Stateless. This is a key principle of PLAY that helps encourage scalability.
  3. Encourages non-blocking asynchronous request handling to further enable scalability (e.g. it can handle more than one request per thread).
  4. Applications can be written in either Scala or Java.
  5. Nice MVC separation (Views, Models, Controllers).
  6. Uses Ebean and JPA for ORM.
  7. Integrated test framework.
  8. Asset compiler (to minify javascript automatically etc…).

The framework reminds me very much of Ruby on Rails, but the fact that it runs on a JVM makes me far more likely to try it.

I particularly like the light-weighted-ness of PLAY. It really embraces the HTTP protocol, not trying to hide it from the developer. This actually gives me more trust as a developer who would be just diving into a new system. Some of the heavier Java frameworks hide too much, resulting in extra time spent trying to figure out how to adjust the long levers of the framework to achieve something as simple as an HTTP redirect.

Ward made note that the stateless aspect of PLAY is important. He said that if you require state (as most applications do), you should relegate this to a store like memcached that can be scaled across multiple instances. This makes a lot of sense. I frequently reach the edge of what can be achieved on a single web server. If you depend too much on “state”, it makes it terribly difficult to introduce a 2nd server effectively. Moving to a “stateless” paradigm enables you to fully leverage the HTTP protocol, introducing caching and proxies effectively at many different positions in the request chain.

comments powered by Disqus