Search code examples
javalambdareactive-programmingproject-reactor

Returning a Mono/Flux in the lambda


I am trying to create a lambda with the below code. Here I am calling an API (API gateway) which in turn calls Second Lambda that returns "Second Lambda" However, when I test it, it's giving below output Doesn't lambda support reactive types as return type in the handler()? Is there any way to return the actual value without using the blocking call block()?

public class FirstLambda implements RequestHandler<Object, Mono<String>> {

    public Mono<String> handleRequest(final Object input, final Context context) {
        String output=null;

        Mono<String> m= WebClient.
                create()
                .get()
                .uri("https://api.amazonaws.com/dev")
                .retrieve()
                .bodyToMono(String.class);

        m.subscribe(x-> System.out.println("inside the mono "+x.toString()));
        System.out.println("Exiting the block");

      
        return m;
    }
}

OUTPUT

{
  "scanAvailable": true
}

Expected OUTPUT

Second Lambda

Second Lambda

public class SecondLambda implements RequestHandler<Object, String> {
    public String handleRequest(final Object input, final Context context) {
        return "Second Lambda";
    }
}

Solution

  • However, when I test it, it's giving below output

    That's because you're not waiting for the Mono to complete before returning, and since the RequestHandler provides no special support for reactive types, it won't wait either.

    Doesn't lambda support reactive types as return type in the handler()?

    Reactive return types aren't supported here in the way you're expecting - but there's also very little reason to use them in this scenario. The main purpose of a reactive framework is to use few threads for many non-blocking requests - but in this setup, your lambda will be run once per request (when the API endpoint is called through API gateway), so there's no advantage whatsoever.

    You can still use WebClient of course, but in this scenario, the only sensible thing to do is to call block() on the WebClient result.