If you’ve ever been working with Project Reactor and have a need to implement an equivalent of a while (or do-while) loop, then you’ve come to the right place 🙂

In this article, I will show you what exactly the expand() method does in Project Reactor and how it can help you to solve the problem of a while (or rather do-while) loop.

2. Project Reactor Expand in Theory

As the first step, let’s try to understand what exactly the Mono.expand() method do? According to the documentation:

Recursively expand elements into a graph and emit all the resulting element using a breadth-first traversal strategy.

I know, it might sound a bit confusing, but let’s look at the following dependency graph:

As we can see, it presents a hierarchical structure of the parent-child relationships. If we would expand a Mono.just(A), then the values would be emitted in the following order: A, B, C, D, E, F, G, H.

This behavior can be used to implement a counterpart of a while loop in Project Reactor.

3. Set Up Example Spring WebFlux Project

With that being done, let’s implement a simple Spring WebFlux project, which will help us to understand everything even better.

We will expose a simple REST endpoint with pagination and use the expand() method to fetch all the results.

[elementor-template id=”9007393″]

3.1. Imports

As the first step, let’s add the necessary import to the project:

dependencies {
  implementation("org.springframework.boot:spring-boot-starter-webflux")
}

3.2. Expose The Test Endpoint

Nextly, let’s expose the example endpoint:

@RestController
@RequestMapping("/api")
class ExampleController(
  private val service: ExampleService
) {

  data class ExampleDto(val name: String, val nextPageToken: String?)

  val exampleList = mapOf(
    "" to ExampleDto("Name-1", "token-2"),
    "token-2" to ExampleDto("Name-2", "token-3"),
    "token-3" to ExampleDto("Name-3", "token-4"),
    "token-4" to ExampleDto("Name-4", "token-5"),
    "token-5" to ExampleDto("Name-5", null)
  )

  @GetMapping("/example")
  fun getExample(@RequestParam("token") pageToken: String?): Mono<ExampleDto> =
    pageToken?.let { token ->
      Mono.just(exampleList[token]!!)
    } ?: Mono.empty()

}

As we can see, the logic is pretty straightforward.

When the API consumer performs a GET request with an empty String, the endpoint returns the name and nextPageToken properties:

{
    "name": "Name-1",
    "nextPageToken": "token-2"
}

The nextPageToken property can be then used to iterate through the entries in the Map. Finally, when the user gets the last record, the nextPageToken property is null and the following request results in the empty Mono being returned.

as a note, I can add that the Google Calendar API works in a similar manner 🙂

4. Project Reactor While Loop

So at this point, we already have our REST endpoint and it’s time to consume it with a do-while loop in some way.

4.1. Add WebClient Config

As the first step, let’s add the WebClient config:

@Configuration
class Configuration {

  @Bean
  fun webClient(): WebClient =
    WebClient.builder()
      .baseUrl("http://localhost:8080")
      .build()

}

4.2. Create Example Service

Nextly let’s implement the ExampleService and a performRequest function:

@Service
class ExampleService(
    private val webClient: WebClient
) {
  
  private fun performRequest(token: String?): Mono<ExampleController.ExampleDto> =
    webClient
      .get()
      .uri { builder ->
        builder
          .path("/api/example")
          .queryParamIfPresent("token", Optional.ofNullable(token))
          .build()
      }
      .retrieve()
      .bodyToMono(ExampleController.ExampleDto::class.java)
}

As can be seen, this function is responsible for performing a GET request to the http://localhost:8080/api/example endpoint. The token query parameter is set based on the passed argument (which can be null, as well).

4.3. Make Use Of Mono.expand() Method

Finally, let’s make use of the Project Reactor Mono.expand() method to iterate through the results in a do-while style:

operator fun invoke() {
  performRequest("")
    .expand { response ->
      performRequest(token = response.nextPageToken)
    }
    .subscribe(System.out::println)
}

Now, when we invoke the above function, the following values will be printed to the output:

ExampleDto(name=Name-1, nextPageToken=token-2)
ExampleDto(name=Name-2, nextPageToken=token-3)
ExampleDto(name=Name-3, nextPageToken=token-4)
ExampleDto(name=Name-4, nextPageToken=token-5)
ExampleDto(name=Name-5, nextPageToken=null)

As we can see, the initial Mono has been expanded and the values are published until the endpoint returns the empty Mono.

5. Summary

And that would be all for this article on how to implement a while (do-while) loop in Project Reactor.

As always, you can find the source code right here, in this GitHub repository, and the other articles related to Project Reactor here.

If you would like to add anything, or just simply share your thoughts, then please let me know in the comment section. Have a great week and see you in the next articles 🙂

The post While Loop In Project Reactor? Expand as a Solution. appeared first on Codersee blog- Kotlin on the backend.

In the previous article, we’ve covered the basic differences between Mono.just(), defer(), fromSupplier() and create() methods. If you haven’t seen it yet, I highly recommend you to take a while and check it out.

Although we’ve spent quite some time trying to understand the behavior and possible use cases for each method, it’s worth to mention that we focused on successful cases. Unfortunately, this is not always the case in real-life scenarios. Provided that, in this article we will focus on how the mentioned methods vary in exceptions and null handling and what should we be aware of.

2. Imports

As the first step, let’s import the necessary library to our project:

implementation("io.projectreactor:reactor-core:3.4.12")

3. Null Handling

After that, we can start can start practicing with nulls, also known as The Billion Dollar Mistake. Even though the Kotlin provides us a great support in null prevention, they can still occur- either on purpose (hopefully), or by mistake.

Given that, let’s prepare a function called nullReturningDateFetching:

private fun nullReturningDateFetching(): LocalDateTime? {
    Thread.sleep(500)
    println("GETTING DATE")
    return null
}

As a word of explanation- we expect that the above code will cause the current thread to sleep, following by printing GETTING DATE and returning a null value.

3.1. Mono.just()

As the next step, let’s start with the Mono.just() method- just like in the previous article:

private fun monoJustNull(): Mono<LocalDateTime> =
    Mono.just(nullReturningDateFetching())

fun monoJustNullSubscription() {
    val myMono = monoJustNull()
    myMono.subscribe(::println)
    myMono.subscribe(::println)
    myMono.subscribe(::println)
}

fun monoJustNullInstantiation() {
    val myMono = monoJustNull()
}

And let’s run both methods:

// monoJustNullSubscription
GETTING DATE
Exception in thread "main" java.lang.NullPointerException: value

// monoJustNullInstantiation
GETTING DATE
Exception in thread "main" java.lang.NullPointerException: value

As we can clearly see, both cases completed with the same result- thrown NullPointerException. Whatsoever, if we used an IDE, like IntelliJ, it warned us about type mismatch! The reason behind that is pretty straightforward- internally, the Mono.just() method creates a MonoJust class instance, which requires a constructor argument to be not-null.

Additionally, we can’t implement any callback behavior using error-handling operators, like onErrorReturn(). The only possibility to recover in this case would be to wrap the Mono.just(nullReturningDateFetching()) with a try-catch block and personally, I find this solution a bit ugly.

Thankfully, if we really need to use the Mono.just() and the value we would like to wrap can be null, a Mono class ships with the justOrEmpty() method. Instead of throwing exception, it will emit an onComplete signal, which we can fallback with, for instance, defaultIfEmpty().

3.2. Mono.defer()

As the next example, let’s figure out how does the Mono.defer() works:

Note: the following examples will focus on the subscription part- the reason for this has been covered in the previous article.

fun monoDeferNull(): Mono<LocalDateTime> =
    Mono.defer { null }
 
fun monoDeferSubscription() {
    val myMono = monoDeferNull()
    myMono.subscribe(::println)
    myMono.subscribe(::println)
    myMono.subscribe(::println)
}

Nextly, let’s check the result:

// monoDeferSubscription
// 3x:
[ERROR] (main) Operator called default onErrorDropped - reactor.core.Exceptions$ErrorCallbackNotImplemented: 
java.lang.NullPointerException: The Mono returned by the supplier is null
reactor.core.Exceptions$ErrorCallbackNotImplemented: java.lang.NullPointerException: The Mono returned by the supplier is null
Caused by: java.lang.NullPointerException: The Mono returned by the supplier is null

As we might have noticed, the exception seems to be exactly the same. However, it has been caught internally and propagated into the onError signal. For that reason, the number of messages is equal to the number of Subscribers we’ve created.

Let’s take a while to see what happens underneath:

try {
    p = Objects.requireNonNull(supplier.get(),
            "The Mono returned by the supplier is null");
}
catch (Throwable e) {
    Operators.error(actual, Operators.onOperatorError(e, actual.currentContext()));
    return;
}

We can clearly spot, that this code is responsible for the message we’ve received. The Operators.error itself is responsible for calling the onError method of our Subscribers.

On the positive side, this behavior allows us to recover with some error-handling operator, like:

fun monoDeferSubscriptionRecover() {
    val myMono =
            monoDeferNull()
                .onErrorReturn(LocalDateTime.MIN)

    myMono.subscribe(::println)
    myMono.subscribe(::println)
    myMono.subscribe(::println)
}
// Result:
-999999999-01-01T00:00
-999999999-01-01T00:00
-999999999-01-01T00:00

3.3. Mono.fromSupplier()

Nextly, let’s check the Mono.fromSupplier() method:

fun monoFromSupplierNull(): Mono =
    Mono.fromSupplier { nullReturningDateFetching() }

fun monoFromSupplierSubscription() {
    val myMono = monoFromSupplierNull()
    myMono.subscribe(::println)
    myMono.subscribe(::println)
    myMono.subscribe(::println)
}

Similarly, let’s see the result:

// monoFromSupplierSubscription
GETTING DATE
GETTING DATE
GETTING DATE

This time, no exception has been thrown. In practice, the fromSupplier() method just completes empty when the provided Supplier ( nullReturningDateFetching() in our case) resolves to null. Although we got rid of exception, we need to be aware of that and handle it accordingly. Indeed, the Mono class ships with defaultIfEmpty method, which could be used here.

3.3. Mono.create()

As the last example of null handling, let’s see the Mono.create() behavior:

private fun monoCreateNull(): Mono =
    Mono.create { monoSink -> monoSink.success(nullReturningDateFetching()) }

fun monoCreateNullSubscription() {
    val myMono = monoCreateNull()
    myMono.subscribe(::println)
    myMono.subscribe(::println)
    myMono.subscribe(::println)
}

And again, let’s run the above code:

// monoCreateNullSubscription
GETTING DATE
GETTING DATE
GETTING DATE

As we can see, result itself is exactly the same, as in the previous example. However, the reason is slightly different and pretty well explained in the documentation itself:

Calling this method [ success(T) ] with a null value will be silently accepted as a call to success() by standard implementations.

As a result, the silently accepted success() call completes without any value.

3. Exceptions Handling

With all of that being explained, we can finally focus on their differences in exceptions handling.

Just like previously, let’s start with another date fetching variant, called exceptionDateFetching:

private fun exceptionDateFetching(): LocalDateTime {
    Thread.sleep(500)
    println("GETTING DATE")
    throw RuntimeException("ERRORS HAPPEN")
}

Unlike the previous paragraph, let’s perform a collective comparison of all methods:

private fun monoJustException(): Mono<LocalDateTime> =
Mono.just(exceptionDateFetching())

private fun monoDeferException(): Mono<LocalDateTime> =
    Mono.defer { monoJustException() }

private fun monoFromSupplierException(): Mono<LocalDateTime> =
    Mono.fromSupplier { exceptionDateFetching() }

private fun monoCreateException(): Mono<LocalDateTime> =
    Mono.create { monoSink -> monoSink.success(exceptionDateFetching()) }

After running all of them, we should see the following result:

// monoJustExceptionSubscription
GETTING DATE
Exception in thread "main" java.lang.RuntimeException: ERRORS HAPPEN

// monoDeferExceptionSubscription & monoFromSupplierExceptionSubscription & monoCreateExceptionSubscription
// 3x
GETTING DATE
[ERROR] (main) Operator called default onErrorDropped - reactor.core.Exceptions$ErrorCallbackNotImplemented: 
java.lang.RuntimeException: ERRORS HAPPEN
reactor.core.Exceptions$ErrorCallbackNotImplemented: java.lang.RuntimeException: ERRORS HAPPEN
Caused by: java.lang.RuntimeException: ERRORS HAPPEN

As we can see- when using the Mono.just() method, we have to explicitly make sure that all exceptions are handled within the function responsible for date-time creation. Without that, the exception will be thrown on the instantiation and lead to thread termination.

On the other hand, the rest of the methods will log an error and finally, throw it via Exceptions.bubble(Throwable). In other words, the exception will be again caught internally and propagated as an onError signal. As we have already seen, this type of signal might be pretty easily handled with onError* methods.

5. Summary

And that would be all for this article. I really hope, that you will benefit from this, and the previous tutorial describing differences between the Mono.just(), defer(), fromSupplier() and create() methods. Although the Project Reactor is not the most trivial thing in the world, I am 100% sure that you can take advantage of learning it. It will be a pleasure to me to walk you through this process.

Finally, just like always, you can find the source code here. Moreover, if you would like to ask about anything or you have some suggestions about future topics, please let me know about it in the comment section below, or by using the contact form.

If you find this material useful, you might be interested in my previous articles:

• What is Kotlin and Why Should You Learn It?
• Mono.just() vs defer() vs fromSupplier() vs create() – Part 1
• Micronaut with MongoDB and Kotlin

The post Mono.just() vs defer() vs fromSupplier() vs create() – Part 2 appeared first on Codersee blog- Kotlin on the backend.

In the first article of a series related to the Project Reactor, I would like to show you the process of creating Monos with Mono.just(), Mono.defer(), Mono.fromSupplier() and Mono.create() methods. After this step by step tutorial, you will have a decent understanding of each method and differences between them.

Nonetheless, this is not an introduction to the Project Reactor and to get the most out of this article, you need to understand at least the basic concepts associated with it. Considering that, I highly recommend their official docs, but if you would be interested in a video explanation, please let me know in the comments section below.

As the last thing in the introduction I would like welcome you to the Codersee after a long period of time. Last 12 months have been a pretty tough time for me and I had to suspend all of my blog activities. Nevertheless, I am back to blogging bringing you new portion of knowledge and ideas. I am so excited about upcoming months and really hope that you will be too.

2. Eager vs Lazy Evaluation

Before we start considerations about Mono creation, let’s take a while to understand the difference between eager and lazy evaluation. In general, both terms describe the way expressions are evaluated. With eager evaluation, the value will be evaluated immediately, when the instruction has been encountered. In the second case, the process will be delayed until the value is really needed, hence the term- lazy evaluation.

[elementor-template id=”9007393″]

3. Hot vs Cold Publishers

Another terms I would like to cover before heading to the clue of this article are hot and cold publishers. In Project Reactor all Publishers (like Monos or Fluxes) are considered either one of them. Cold publishers, generate new data for each subscription (consider it a bit similar to lazy evaluation), whereas hot publishers are independent of subscribers and will produce data anyway (similarity to eagerness).

Undoubtedly, the two above paragraphs are just a brief summary and I highly recommend you do a further investigation. However, I am pretty sure that this knowledge will be sufficient for the purpose of this tutorial.

4. Imports

With that being said, let’s start by importing necessary library to our project:

implementation("io.projectreactor:reactor-core:3.4.12")

Note: you can find the source code for this article, as always, in our GitHub repository.

5. Create Monos

After that, let’s define what exactly a Mono is in terms of Project Reactor? Well, it’s nothing else than just a specialized Publisher capable of asynchronous emitting of either 1 or 0 element. Fluxes, on the other hand, represent an asynchronous sequence of 0 to N elements.

4.1. Mono.just()

Provided that, let’s start everything with an example function called successfulDateFetching:

fun successfulDateFetching(): LocalDateTime {
    Thread.sleep(500)
    println("GETTING DATE")
    return LocalDateTime.now()
}

As we can see, it will be responsible for three things:

• causing the currently executing thread to sleep,
• printing the text to the output,
• and finally, returning the current date-time information from the system clock

As the next step, let’s let’s implement the following Mono.just() example:

fun monoJust(): Mono<LocalDateTime> =
    Mono.just(successfulDateFetching())

fun monoJustSubscription() {
    val myMono = monoJust()
    myMono.subscribe(::println)
    myMono.subscribe(::println)
    myMono.subscribe(::println)
}

fun monoJustInstantiation() {
    val myMono = monoJust()
}

The above code is responsible for creating a new Mono inside the monoJust function and after that it’s utilized inside the monoJustSubscription or monoJustInstantiation methods. Given that, it’s worth to quote the Reactor documentation here:

Nothing Happens Until You subscribe()

And that’s one of the most important things when dealing with Reactor- data do not start pumping into by default. By creating a Mono, we’re just defining an asynchronous process, but all the magic happens when we tie it to a Subscriber. Personally, I would compare that to the process of class definition– just like a class is a simple skeleton with some predefined behavior until we create it’s instance, so here a Mono defines the process of data flow until we subscribe to it.

Note: As always, I highly encourage you to copy and run all of the examples manually, so that you could get the most out of this article.

With that being said, we expect that that a date-time information will be printed 3 times after running monoJustSubscription and nothing happen in second scenario. Let’s validate if it’s true:

// monoJustSubscription
GETTING DATE
2021-12-08T07:58:22.053724500
2021-12-08T07:58:22.053724500
2021-12-08T07:58:22.053724500

// monoJustInstantiation
GETTING DATE

As you might have noticed- the result seems to be a bit odd. Why are the printed values exactly the same in the first case and why does the GETTING DATE has been even printed without subscription?

Basically, this is the main difference between a Mono.just() and the rest of the methods we’ll compare in this article. It is a hot publisher and the value has been captured at the instantiation time. In fact, the successfulDateFetching() has been invoked when we created and instance of Mono- even if we didn’t subscribe to it! Undeniably, we should be aware of this behavior especially when dealing with multiple subscribers.

4.2. Mono.defer()

Thankfully, Mono.just() is not the only possible way of creating Monos. Let’s see what can we do to delay the process of obtaining the date-time with Mono.defer():

fun monoDefer(): Mono<LocalDateTime> =
    Mono.defer { monoJust() }

fun monoDeferSubscription() {
    val myMono = monoDefer()
    myMono.subscribe(::println)
    myMono.subscribe(::println)
    myMono.subscribe(::println)
}

fun monoDeferInstantiation() {
    val myMono = monoDefer()
}

After that, let’s run the examples and see the result:

// monoDeferSubscription
GETTING DATE
2021-12-08T09:01:56.457742200
GETTING DATE
2021-12-08T09:01:56.970125600
GETTING DATE
2021-12-08T09:01:57.487761200

// monoDeferInstantiation 

This time, we’ve achieved a real laziness- a successfulDateFetching() was triggered each time a new Subscriber was registered. Moreover, nothing happened, when we just instantiated a Mono. The reason behind this is pretty straightforward- Mono.defer() will supply a target Mono (created by the monoJust(), in our case) to each Subscriber. In fact, the delay between each subscription could be extended to whatever value we would like to, and the printed date-time would be up to date each time.

At this point, we can clearly see that these two methods serve different purposes. If we are dealing with some constant data, or data set, or we are just OK with the data being obtained eagerly, then the Mono.just() should be the choice. On the other hand, if we want the subscriber to receive data calculated at the time of subscription, then the Mono.defer() should be picked to “wrap” another Mono.

4.3. Mono.fromSupplier()

Similarly to defer(), we can delay the data evaluation with Mono.fromSupplier() case. As the documentation states, it allows us to:

Create a Mono, producing its value using the provided Supplier. If the Supplier resolves to null, the resulting Mono completes empty.

Given that’s let’s see the following example:

private fun monoFromSupplier(): Mono<LocalDateTime> =
    Mono.fromSupplier { successfulDateFetching() }

fun monoFromSupplierSubscription() {
    val myMono = monoFromSupplier()
    myMono.subscribe(::println)
    myMono.subscribe(::println)
    myMono.subscribe(::println)
}

fun monoFromSupplierInstantiation() {
    val myMono = monoFromSupplier()
}

In this case, the output presents as follows:

// monoFromSupplierSubscription
GETTING DATE
2021-12-08T08:33:59.168426800
GETTING DATE
2021-12-08T08:33:59.671269400
GETTING DATE
2021-12-08T08:34:00.187244300

// monoFromSupplierInstantiation

We can clearly spot that this, and Mono.defer() execution worked exactly the same. As a word of explanation- both methods serve us to delay (defer) the moment of capturing the value. Most of the time, we ill lean toward them when dealing with external libraries, or another part of the code that we do not have an influence on. To put it simple, our choice will be:

• Mono.defer()– when dealing with another library, method or whatever else returning a Mono instance
• Mono.fromSupplier()– when consuming a simple value being returned from external (not a Mono)

Additionally, it’s worth mentioning that Project Reactor ships with another method called fromCallable(), which you might be interested in, as well (but considerations on Supplier and Callable usage won’t be a part of this article).

4.3. Mono.create()

Lastly, let’s have a look at Mono.create(). Despite it’s simple name it is the most advanced way of creating Monos covered in this article. Again, I highly recommend you to check out the official documentation for more thorough exaplanation and examples.

As a word of clarification- Mono.create() allows us to deal with internal Mono signals through the MonoSink<T> wrapper’s create(), create(T) and error(Throwable) methods. Similarly, it creates a deffered emitter, I believe the result of the following example is just a formality:

fun monoCreate(): Mono =
    Mono.create { monoSink ->
        monoSink.success(successfulDateFetching())
    }

fun monoCreateSubscription() {
    val myMono = monoCreate()
    myMono.subscribe(::println)
    myMono.subscribe(::println)
    myMono.subscribe(::println)
}

fun monoCreateInstantiation() {
    val myMono = monoCreate()
}

// #Result
// monoCreateSubscription
// GETTING DATE 2021-12-08T08:33:59.168426800
// GETTING DATE 2021-12-08T08:33:59.671269400 
// GETTING DATE 2021-12-08T08:34:00.187244300 

// monoCreateInstantiation

As we might have noticed, the instantiation process is deferred here, just like when dealing with defer() and fromSupplier() methods. Nevertheless, it is the most advanced method presented in this tutorial which gives us much more control over emitted values and in most cases- it’s usage won’t be necessary. On the other hand, it might be a great choice when dealing with some callback-based APIs.

5. Conclusion on Mono.just() vs defer() vs fromSupplier() vs create()

Finally, let’s have a quick recap on Mono.just() vs defer() vs fromSupplier() vs create():

• Mono.just()– value captured at the time of instantiation, each Subscriber will receive the same value
• Mono.defer()– supplies a target Mono to each Subscriber, so the value will be obtained when subscribing
• Mono.fromSupplier()– produces a value using provided subscriber on subscribe
• Mono.create()– creates a deferred emitter, the most advanced method allowing to operate on MonoSink<T>

6. Summary

And that’s all for the first article describing differences between Mono’s just(), defer(), fromSupplier() and create() methods. Additionally, in the next episode, we will focus on differences in null and exceptions handling.

Finally, I really hope that after this read you’ll get a better understanding of their behavior and use cases. For the source code, please refer to this GitHub repository. Moreover, if you would like to ask about anything or need some more explanation, please do it in the comment section below, or by using the contact form.

The post Mono.just() vs defer() vs fromSupplier() vs create() – Part 1 appeared first on Codersee blog- Kotlin on the backend.