BT

Your opinion matters! Please fill in the InfoQ Survey!

Evaluating Play for Composing Web APIs

| by Jean-Jacques Dubray Follow 3 Followers on Jul 06, 2011. Estimated reading time: 1 minute |

A note to our readers: As per your request we have developed a set of features that allow you to reduce the noise, while not losing sight of anything that is important. Get email and web notifications by choosing the topics you are interested in.

Yevgeniy Brikman, Principal Software Engineer at Linked In, published a summary of his evaluation of the Play framework, a Java Web Framework.

The thing that really caught my eye was Play's support for asynchronous programming, which would be immensely useful for fetching data from our many backend services in parallel and supporting comet-style interactions.

Play is intended to work with very short requests which can have an arbitrary response time. Play temporarily “suspends” the HTTP requests which remain connected. This requires minimal resources while the process waits, in particular, Play is capable of working of a mini-thread pool (typically the number of processors on your machine plus one). This is what is very different from the “one thread per request” which has been prevalent until now.

Depending on the load profile of the server, the evented approach may allow a far greater degree of concurrency than the threaded model; for persistent connections as in comet, the evented model is the only way to go.

Play offers several models to handle requests asynchronously. One can define “Promise” values (which can be composed to into a “waitall” statement), in that case, the execution suspends until all the requests have returned which comes handy when you need to fetch data from multiple Web APIs for instance. Play also supports a callback model using Java anonymous inner classes. Play also allows to define a fixed time after which the request is handled.

the community seems very active, hot reload works as advertised, it's reasonably DRY, and the support for async I/O is as good as I've seen in the JVM world. There are a few gotchas and the documentation/JavaDoc needs some improvement, but we will be evaluating Play further to see if it fits in the LinkedIn ecosystem.

With the rise of (mobile) composite applications and Web APIs, it seems that a thin composition middle-tier which acts an intermediary between (mobile) clients and Web APIs is emerging. Could frameworks like Play or Node.js will become critical to mobile solution architectures? What’s your take on it?

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Play is great by Will Iverson

I've been using it for personal projects for some time now, and been VERY happy with it. The use of standard Java syntax makes it much more usable in the rest of the developer ecosystem than, say, Grails.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

1 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT