Introduction to Play Framework

Prelude

This tip quickly touches upon the most interesting features of Play! Framework that make it an attractive framework for web application development. It also conceptually looks at some of the best practices around designing applications using Play!.

Introduction

Information Technology is evolving at an astounding pace. The hardware, processors, network, communication protocols, programming languages, paradigms, testing patterns, deployments architectures, Application models, etc. are all changing. So the professional life of a typical IT professional/developer is already over-burdened keeping pace with this evolution.

Also web applications have come a long way since, the static corporate web pages of yesteryears were reshaped into dynamic interactive and useful applications. They are increasingly becoming ubiquitous and critical to businesses worldwide and are an essential part of the enterprise strategy. Building these is also becoming increasingly complex and time-consuming.

This is where web application frameworks come into play and using them to build/deploy/test applications overcome some of the above mentioned challenges.

What is a Web Application Framework by the Way?

So let's answer this basic question.

Wikipedia defines web application framework (WAF) as:

‘A software framework that is designed to support the development of dynamic websites, web applications, web services and web resources. The framework aims to alleviate the overhead associated with common activities performed in web development. For example, many frameworks provide libraries for database access, templating frameworks and session management, and they often promote code reuse.’

Why We Need Frameworks BTW?

Apart from the reasons mentioned above in Wikipedia definition, there are a plethora of other advantages the current list of web frameworks offer, some of which are given below:

• Expedited development cycles because of built-in automation features and support.
• Support best practices and leveraging for emerging impactful technologies like Cloud Computing
• Support for exploiting newer multi-core processors based architectures delivering better and better performance.
• Supporting ubiquitous browsers of every shape and size and asserting the BYOD (bring-your-own- device) culture.

Now let's look at the Play! framework.

What is Play! Framework?

Again from Wikipedia, the definition goes like this:

‘Play is an open source web application framework, written in Scala and Java, which follows the model–view–controller (MVC) architectural pattern. It aims to optimize developer productivity by using convention over configuration, hot code reloading and display of errors in the browser (dev mode for debugging) ‘

Features of the Play! Framework?

Mentioned below are some of the most compelling features:

1. Sensible ‘convention over configuration’ design that gets the developer out of the ‘Configuration XML miseries’ introduced by contemporary and popular frameworks
2. Hot-code reloads which allow you to change code in your favorite IDE and hit reload on browser UI page to trigger auto-compile-package-deploy-run cycles for faster incremental developments
3. Push based MVC stack with Template, Persistence and Testing Engines that promote great code re-use, pluggability and TDD style development
4. Renders itself well to enterprise continuous integration setups like, Jenkins, Calimoucho and CM tools like GIT
5. Share-nothing reactive style server-side framework that makes developing modern BYOD style RESTful Apps development easy. Also supports asset compilers and WebSockets
6. Is Cloud-aware and is NOSQL friendly using its purpose specific add-on modules
7. Supports simple to federated security using out-of-the-box using add-ons modules
8. Supports coding in conventional (Java if you need to) as well as newer programming languages like Scala leveraging the performance-oriented reactive code

(Note: The newer languages also take advantage of multicore processors to schedule parallel processing when possible, use immutable objects and use localized concurrency designs like actors-based code that eliminate the pain out of concurrent state design and code.)

Design Considerations using Play Framework

It all starts with the MVC and the modularity mindset.

The Model

Model objects in Play aren’t dumb exactly like elsewhere. Models have the responsibility to maintain their integrity. The lesser the getters-setters and more the idempotent your model objects are… the better is your model design! Shared state and concurrency handling threads are the things that you should shun if possible.

Also, avoid using the common Java anti-pattern Anemic domain model so that you localize data with needed behavior and cap them into useful objects that know to preserve their integrity.

Also, often you may find a single model object may not be able to hold your business logic without becoming too fat. In that case, you can use generalization-specialization pattern to hold purpose-specific logic in sub-classes’ objects to have a cleaner design.

Avoid model objects directly servicing end-user calls ….that should be done by controllers. Also, presentational code, e.g., HTML snippets, text-font formatting details, etc. should not be part of model state or model data.

The Controller

Controllers provide a place for holding your application’s behavior and navigation aspects. Designing controllers that map upon the application functionality which itself is segregated by modularity pays well in the long run in terms of easier maintenance and bug localization. Another often misused concept of chaining controllers is equally a bad idea in Play!. Having heavy branching logic in one or more controllers to get higher order abstractions for actions is a bad idea anyway! Avoid the temptation to do so.

Using immutable libraries (in Java or Scala) will usually render better design and scalability and performance and also further the cause for ‘Reactive Design’.

The other aspect that Play! allows is to specify the routing of URLs to specific controller methods allows for full-grain fine mapping of functionality to the underlying code in a very RESTful paradigm. This highly helps in building, debugging and scaling RESTful applications better.

Controllers should create model instances and manipulate the state based on user actions or needs of the business logic. They should not contain database specific code, nor should contain database specific commands like SQL.

The View

Views in Play! are responsible for presenting the Model state to end user in a needed format or in a specific UI style. Hence they should only contain presentation code. They should avoid explicit GET and PUT like HTTP requests, since that is the responsibility of the Controller. They should also avoid explicit SQL statements to get the data. They can use controllers methods for that.

The Template engine in Play! provides Java-JSP like tags and other goodies (either with Java or Scala) for the Java world developers coming into the Play! world. Use the objects like session, flash, request, params, messages, out available implicitly.

Templates in Play! provide a great way for designing bricks of your UI and assembling them dynamically for the needed purpose. Go for them to compose your applications ground-up rather than building monoliths with dynamic DOM manipulation. Use them to build partial views for effective re-use.

Another best practice is to decouple your RESTful server-side API and build a rich and powerful UI using JQuery/AngularJS/ExpressionJS/D3j.s etc. using JSON objects as a glue. This helps in the long-run designing, building, scaling adapting your apps to newer devices and computing landscapes.

Some Other Best Practices

In Play! Controller objects, results are designed to be immutable. This can be used to an advantage by using caching along with it. This can help you scale your application further.

Using Session objects to store all kinds of data whether needed or not at that point in time is a common mal-practice. This causes huge memory bloat and overall performance degradation. Play! doesn’t support session objects but uses cookies to maintain browser state. This makes the play application cluster-ready and scalable from your first deploy cycle.

Using Async programming model further helps your application to scale in real life. Play! uses Akka under the hood to support the async model using actors. Use the async paradigm which under the hood uses Futures and Promises to deliver performance and scalability significantly higher than the usual sync code.

Also use Play! add-on modules like GAE, PDF-generator, MongoDB, Secure Social like OpenID, Oauth, etc. to leverage the best practices and enable your applications to adapt to newer persistence and UI interfaces.