Mixing synchronous and asynchronous methods

[sume]

My team recently moved to the Play framework and we are trying to figure out how to make the best use of programming in a reactive way. Here is one example of what we are dealing with...

public static Promise<Result> fightRequest() {

1        JsonNode request = request().body().asJson();
2        BoxingRequest boxingRequest = BoxingUtil.createBoxingRequest(request);
3        Logger.debug("Float like a butterfly, sting like a bee");
4        return BoxingService.getBoxingDetails(boxingRequest).map(boxingResponse -> ok(Json.toJson(boxingResponse)));
    }


The call to BoxingUtil.createBoxingRequest(request) at line 2 is a synchronous call. While this method is neither an I/O, Database or network call, it still does some processing.  So my question is:

A) Does it make sense if we convert signature of the call at line 2 so that it returns a Promise<BoxingRequest> allowing us to chain the calls with map/flatmap? Will that make our controller method asynchronous?

B) When will returning Promise<T> instead of just T become overkill, does it have to be done only on long running processes? I am asking this as we would like to have a consistent guideline on how to write service methods and
    we are trying to figure out if it makes sense to enforce such a rule

C) What execution context will methods that return a Promise<T> but are called from the controller using? I read that just wrapping a computation in a Future/Promise will just make it run in another thread
    but it will still use up resources that belong to the controller (default execution context) .  If we have service/utility methods that do processor/IO/network intensive calls, how can we make the best reactive applications? Is making them
    asynchronous enough or do we need to provide a separate execution context? (and where do we do that?)

I hope my question is not too hard to follow, I'm not clear on too many things :)

Thanks

[Christian Schmitt]

It really depends what it does, you could also have a Promise.pure() which just is a finished Promise/Future. Currently when something does some heavy work it's mostly best to have some custom executor for it, if it doesn't do much or only runs some minor processing it's best to just return a Promise.pure() or don't run a promise at all.

The question here would be what does boxingRequest do, and what happens when getBoxingDetails fail.

It wouldn't be great to run boxingrequest if getboxing details fail!