LinkedIn expects to adopt Play more widely over time as they develop new features on the site.

LinkedIn is also investigating Play as the underlying technology for its backend services. They are in the process of moving their entire service architecture to RESTful JSON and are looking at Play to help with this process.

Rapid Code and Test Cycle

For developers, a killer Play feature is its ability to dynamically recompile the application when they press “reload” in the browser. LinkedIn developers save their changes in their editor, switch to the browser, and press reload. If there are compilation errors, they show up right in the browser. If the build succeeds, the new page shows up.

This simple feature saves countless hours when developers are working on getting a web application just right.

To keep it snappy when developers press reload, Play uses sophisticated incremental compilation techniques to rebuild only those classes that have changed.

Extensible to Custom Asset Types

Play’s hot reload capabilities can be extended to support new asset types.

LinkedIn has a REST framework using Apache Avro. Java classes are generated from declarative data models and endpoint descriptions.

LinkedIn created an infrastructure for building these REST servers with Play. They also extended Play to support hot-reloading the Avro schemas; after changing a schema, LinkedIn developers just press reload in the browser to regenerate the Java classes and rebuild the app. Any errors appear immediately in the browser.

This saves a developer a couple of minutes every time they make a change.

New kinds of templates can be added to Play via its module system. LinkedIn implemented a Play module to support Dust templates. As always with Play, Dust templates can be hot-reloaded.

Asynchronous, Stateless Scalability

The Play offers two big-picture wins when it comes to scalability.

It supports asynchronous requests, meaning it does not require you to tie up a thread while requests are in progress. Requests can be suspended while the app server waits on an external service or database and then resumed when results are available. This greatly reduces memory requirements for an outstanding request (typically, the thread Platform uses far more memory than the request-servicing code).

As part of the integration process at LinkedIn, Play’s Java API for asynchronous request handling was improved, and the changes were incorporated into the mainline Play codebase and the NashTech Platform Solution.

Play has a stateless design, meaning it does not rely on a server-side session state. Instead, the session state is kept in a cookie and is therefore available to any server node that receives a request.

In a stateless architecture, adding capacity is as easy as adding more application servers. Play gets this right by default and avoids complexity, such as session affinity, that can result in scalability problems.

Flexibility

When evaluating any framework, flexibility is key; because Play has the right architecture out of the box, LinkedIn didn’t need to worry about extensive custom modifications that could impede their ability to move to future releases of the framework.

Play has defined extension points, so those customisations can be external modules rather than patches to the core framework. Apache Avro schema and Dust template support were implemented as modules.