When should a method return a Promise instead of actual result in Play Framework?

Question

I'm relatively new to Play Framework. The current project I'm working on has tons of Promises returned by the service layer components all the way down to controllers. I wonder if that's the best practice. In my opinion, using Promises really clutters up the sources. And I have to make use of final modifiers too frequently just to make local variables, parameters, and class members accessible to anonymous Function I need to create for these Promises. It even affects the way I create my unit test cases. It feels ugly honestly and there's simply too much lines of code than necessary. I'm not even sure if we're doing it right, I feel like we're overusing Promises.

I'm using Java by the way.

So, when should I use a Promise, when should I return a Promise, and when should I not use a Promise? Should all our services and interfaces return a Promise? Is there any better way of doing this? In plain English please.

Drank

Isnt this just a matter of sync vs async? i.e u return a Promise only when a Promise is all you can afford to return. – Kanara

Answer 1

Promises are used when you are doing an operation that is expensive and relatively time-consuming. For example, if you were doing a intensive query on a database, you don't want to leave your front end user waiting while you collect all the records.

In such cases, you would return a Promise instead of a Result. This will stop the front-end from hanging due to it waiting for a response for an intensive computation. It will receive the actual result once the computation is complete.

Promises are run in a separate thread, so only use them when necessary. In most cases, you just need to use a Result.

There is a good page in the Play! Framework documentation that talks all about Asynchronous HTTP programming:

A Promise will eventually be redeemed with a value of type Result. By using a Promise instead of a normal Result, we are able to return from our action quickly without blocking anything. Play will then serve the result as soon as the promise is redeemed.

If you need to stream data, I would also take a look at EventSource (For server sent events) or WebSockets. I would also recommend looking at the latest release of Play (2.3) and getting Java 8 to take advantage of Lambda Expressions, which will reduce the verbosity of code. You can take a look at some examples on Typesafe here.

Oh, and it does look like you are overusing Promises. You only need them if you are doing a computation that is expensive in time and computational resources. Again, if your code is looking unreadable due to anonymous inner classes and functions, I would highly recommend upgrading to Java 8 and using Lambda Expressions.

Stockman

It seems lambda expressions don't eliminate the need for final variables which means you'll only be saving a few characters off your screen. – Drank

You write "This will stop the front-end from hanging". Assuming the client has made the request over HTTP I guess it has to "hang" anyway until the HTTP response is received. I mean the HTTP protocol doesn't have any way to communicate a promise of a response in the future, has it? – Ostensory

@Ostensory I'm not entirely sure about the inner workings of the Promise, but there are async AJAX and HTTP calls available to use. And HTML5 has features that doesn't require the browser to request data, but can accept a stream of incoming data (Server Sent Events and WebSockets). – Stockman

Answer 2

Though it's an old thread, leaving the response from the latest documentation of Play to clarify the followup question in comments that how to handle the Promise response on client side. With Play, the client side would remain blocked waiting for response, while the server would not be blocked for I/O if the controller returns a Promise. Eventually, the Promise would be redeemed and the result of I/O would be returned.

...we are able to return from our action quickly without blocking anything. Play will then serve the result as soon as the promise is redeemed.

The web client will be blocked while waiting for the response, but nothing will be blocked on the server, and server resources can be used to serve other clients.

Boiler