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.

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.

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.