DEV Community: Filip Egeric

Structured Concurrency in Practice: CoroutineScope vs StructuredTaskScope [Part 5]

Filip Egeric — Sun, 29 Mar 2026 18:44:26 +0000

This post series assumes familiarity with Kotlin, Java, and Spring Boot.

No AI was used during the writing of this post series.

CoroutineScope vs StructuredTaskScope: Which one to choose?

Let's summarize what it took to build both solutions:

CoroutineScope

We had to add 2 libraries

val coroutinesVersion = "1.10.2"
implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:$coroutinesVersion")
implementation("org.jetbrains.kotlinx:kotlinx-coroutines-slf4j:$coroutinesVersion")

We had to use runBlocking
We had to change the dispatcher (we used Dispatchers.IO)
We had to wrap blocking calls in runInterruptible
We had to pass MDCContext() to runBlocking

StructuredTaskScope

No libraries added, just JDK 25
We had to remember to call join
We had to build some helpers/wrappers to make it smooth: taskScope instead of StructuredTaskScope.open<Any>.use
We had to manually propagate MDC in our wrapper or to explore ScopedValue for this use case

When to use CoroutineScope and why?

Coroutines are, just like Kotlin, very flexible. If our use case involved manual cancellation of subtasks or some more complex concurrency patterns, coroutines and the ecosystem can probably handle it.
If our entire system is non-blocking, using a reactive framework and libraries, then coroutines are the right tool. They will make the code much more readable and less error prone.

When to NOT use CoroutineScope and why?

Coroutines are invasive. The suspend keyword will spread through the codebase like a virus. If the entire system is blocking, introducing coroutines may be disruptive and may take extra care to cover all the edge cases.
If everything is already blocking it's better to make blocking less expensive (by using virtual threads), than to replace it with non-blocking.
If stack traces and debugging are very important

When to use StructuredTaskScope

If we use Java, there is no alternative.
If everything is already blocking.
If we don't mind that it's a preview API.
If we are tired from untangling reactive/non-blocking stack traces
If we want debugging to be easy

When NOT to use StructuredTaskScope

When preview features are too scary for us
When we already have a codebase using reactive/non-blocking code

Conclusion

Both are great, one is old, the other is new, and just like Kotlin and Java, they will continue to learn from each other as they develop further.

Structured Concurrency in Practice: CoroutineScope vs StructuredTaskScope [Part 4]

Filip Egeric — Sun, 29 Mar 2026 18:44:20 +0000

This post series assumes familiarity with Kotlin, Java, and Spring Boot.

No AI was used during the writing of this post series.

Coroutines are an all-in feature

In Part 3 we finally got to a fully working solution, covering all the edge cases. However, we went to some trouble to get there and we had to be extra careful not to miss some of those edge cases.

Some of this trouble is due to the fact we were mixing blocking and non-blocking code. Coroutines are by their nature non-blocking and they are invasive. This means that they tend to spread through the codebase. You mark one function with suspend and then you have to mark all the callers of that function with suspend, and then all the callers of all those functions, and it propagates all the way.

This is why coroutines are an all-in feature. They mostly make sense if the entire codebase is non-blocking and is using coroutines.

All we wanted was 2 calls in parallel

In Part 1, all we wanted to achieve was to execute 2 functions concurrently instead of sequentially. Since we are using Kotlin, coroutines were a natural solution, but it proved to be more complex than we initially expected. Luckily, we have an alternative.

StructuredTaskScope

StructuredTaskScope is a class from JDK whose main purpose is to enable/facilitate structured concurrency in Java. Before this, achieving structured concurrency in Java was nearly impossible, unless we want to use a reactive framework, which gets way more complicated and frustrating than using kotlin coroutines.

Kotlin has full interoperability with Java, so we should have no problem using this API from Kotlin.

Seeing it in action

After replacing coroutines with the new API, here's what we get:

@RestController
@RequestMapping("/books")
class BooksController(
    private val booksRepository: BooksRepository,
    private val reviewsService: ReviewsService,
) {
    private val log = LoggerFactory.getLogger(BooksController::class.java)

    @GetMapping("/{id}")
    fun fetchBook(@PathVariable id: Long): Book = taskScope {
        log.info("[START] $id")

        val book = fork { findBook(id) }
        val reviews = fork { fetchReviewsFor(id) }

        join()

        book.get()
            .copy(reviews = reviews.get())
            .also { log.info("[SUCCESS] Returning ${it.id}") }
    }

    private fun findBook(id: Long) =
        booksRepository.findById(id) ?: throw BookNotFoundException(id)

    private fun fetchReviewsFor(id: Long) =
        reviewsService.fetchReviewsFor(id)
}

It looks very similar to what we had before. Here's what changed:

runBlocking was replaced by taskScope
async was replaced by fork
We have to call the join method after we fork all the subtasks
findBook and fetchReviewsFor are no longer suspending and wrapped in runInterruptible

And if we call the endpoint, it runs in about 1s and produces following logs:

16:46:59.955 [tomcat-handler-0] [requestId=ipr] INFO  c.b.b.BooksController - [START] 3
16:46:59.956 [virtual-57] [] INFO  c.b.r.ReviewsService - [START] Fetching reviews for book with id 3
16:46:59.957 [virtual-56] [] INFO  c.b.b.BooksRepository - [START] Fetching book with id 3
16:47:00.963 [virtual-57] [] INFO  c.b.r.ReviewsService - [DONE] Fetched reviews for book with id 3
16:47:01.011 [virtual-56] [] INFO  c.b.b.BooksRepository - [DONE] Fetched book with id 3
16:47:01.011 [tomcat-handler-0] [requestId=ipr] INFO  c.b.b.BooksController - [SUCCESS] Returning 3

We see that requestId again disappears in some logs, but we'll deal with that later. What's important for now is that we've covered the happy path

Sad path

Changing application.properties

books-repository.delay-in-seconds=3
reviews-service.delay-in-seconds=1
reviews-service.fail=true

And then calling the endpoint produces following logs:

16:51:56.180 [tomcat-handler-0] [requestId=peg] INFO  c.b.b.BooksController - [START] 3
16:51:56.181 [virtual-57] [] INFO  c.b.r.ReviewsService - [START] Fetching reviews for book with id 3
16:51:56.182 [virtual-56] [] INFO  c.b.b.BooksRepository - [START] Fetching book with id 3
16:51:57.209 [tomcat-handler-0] [requestId=peg] ERROR o.a.c.c.C.[.[.[.[dispatcherServlet] - Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed: java.util.concurrent.StructuredTaskScope$FailedException: java.lang.RuntimeException: Something went wrong when fetching reviews] with root cause
java.lang.RuntimeException: Something went wrong when fetching reviews...

This means that the cancellation also works as expected.

That was easy, right?

Well, not really.
taskScope doesn't really exist in JDK or in the Kotlin standard library.

We had to jump through some hoops to make it to work smoothly.

Hoops

If we used the API as it is provided in the JDK, our code would look like this:

@GetMapping("/{id}")
fun fetchBook(@PathVariable id: Long): Book = StructuredTaskScope.open<Any>().use {
    log.info("[START] $id")

    val book = it.fork(Callable { findBook(id) })
    val reviews = it.fork(Callable { fetchReviewsFor(id) })

    it.join()

    book.get()
        .copy(reviews = reviews.get())
        .also { log.info("[SUCCESS] Returning ${it.id}") }
}

Several problems with this:

StructuredTaskScope.open<Any>().use { is too long
We have to use Any because the type parameter for open represents the result type of subtasks and our 2 subtasks have different result types. One returns a Book and the other returns List<Review>.
We cannot call fork like this: it.fork { findBook(id) }. This is because in Java, the fork method has two overrides. One with Callable and the other with Runnable and in Kotlin it defaults to Runnable which has void as a result type. That's why we have to be explicit about Callable. There is even an open issue on YouTrack about this: Prioritize StructuredTaskScope.fork(Callable) over StructuredTaskScope.fork(Runnable)

Kotlin flexibility at its best

To be able to use taskScope { we need only a few lines of helper/wrapper code:

class TaskScope<T, R>(private val scope: StructuredTaskScope<T, R>) : AutoCloseable by scope {
    fun <A : T> fork(fn: () -> A): StructuredTaskScope.Subtask<A> = scope.fork(Callable { fn() })
    fun join(): R = scope.join()
}

inline fun <T, R> taskScope(block: TaskScope<T, Void>.() -> R): R =
    TaskScope(StructuredTaskScope.open<T>()).use { it.block() }

This solves all of the above mention problems:

taskScope { is much shorter than StructuredTaskScope.open<Any>().use {
We don't have to use Any explicitly
We don't have to specify Callable, we simply call it like this: fork { ... }

What about that lost `requestId`?

Looking back at the logs:

17:15:46.571 [tomcat-handler-0] [requestId=uey] INFO  c.b.b.BooksController - [START] 3
17:15:46.573 [virtual-57] [] INFO  c.b.r.ReviewsService - [START] Fetching reviews for book with id 3
17:15:46.573 [virtual-56] [] INFO  c.b.b.BooksRepository - [START] Fetching book with id 3
17:15:47.575 [virtual-57] [] INFO  c.b.r.ReviewsService - [DONE] Fetched reviews for book with id 3
17:15:47.611 [virtual-56] [] INFO  c.b.b.BooksRepository - [DONE] Fetched book with id 3
17:15:47.611 [tomcat-handler-0] [requestId=uey] INFO  c.b.b.BooksController - [SUCCESS] Returning 3

We see that requestId is lost in the middle.
This is because MDC is using ThreadLocal under the hood and ThreadLocal values are not propagated when fork is called.

Since we already created a wrapper class TaskScope, adding this propagation shouldn't be too difficult:

class TaskScope<T, R>(private val scope: StructuredTaskScope<T, R>) : AutoCloseable by scope {
    fun <A : T> fork(fn: () -> A): StructuredTaskScope.Subtask<A> {
        val mdcMap = MDC.getCopyOfContextMap()
        return scope.fork(Callable { 
            MDC.setContextMap(mdcMap)
            fn() 
        })
    }
    fun join(): R = scope.join()
}

This solves our problem:

17:26:42.703 [tomcat-handler-0] [requestId=lef] INFO  c.b.b.BooksController - [START] 3
17:26:42.704 [virtual-57] [requestId=lef] INFO  c.b.r.ReviewsService - [START] Fetching reviews for book with id 3
17:26:42.705 [virtual-56] [requestId=lef] INFO  c.b.b.BooksRepository - [START] Fetching book with id 3
17:26:43.711 [virtual-57] [requestId=lef] INFO  c.b.r.ReviewsService - [DONE] Fetched reviews for book with id 3
17:26:43.759 [virtual-56] [requestId=lef] INFO  c.b.b.BooksRepository - [DONE] Fetched book with id 3
17:26:43.760 [tomcat-handler-0] [requestId=lef] INFO  c.b.b.BooksController - [SUCCESS] Returning 3

But, this feels a bit hacky. A more idiomatic way to achieve the same thing would be to use ScopedValue, but that's a story for another time.

CoroutineScope vs StructuredTaskScope: Which one to choose?

Find out in the next part...

Structured Concurrency in Practice: CoroutineScope vs StructuredTaskScope [Part 3]

Filip Egeric — Sun, 29 Mar 2026 18:44:14 +0000

This post series assumes familiarity with Kotlin, Java, and Spring Boot.

No AI was used during the writing of this post series.

What happened to our logs?

In Part 2 we completed the entire solution, both the happy path and the sad paths. Here's what we ended up with:

@RestController
@RequestMapping("/books")
class BooksController(
    private val booksRepository: BooksRepository,
    private val reviewsService: ReviewsService,
) {
    private val log = LoggerFactory.getLogger(BooksController::class.java)

    @GetMapping("/{id}")
    fun fetchBook(@PathVariable id: Long): Book = runBlocking(Dispatchers.IO) {
        log.info("[START] $id")

        val book = async { findBook(id) }
        val reviews = async { fetchReviewsFor(id) }

        book.await()
            .copy(reviews = reviews.await())
            .also { log.info("[SUCCESS] Returning ${it.id}") }
    }

    private suspend fun findBook(id: Long) = runInterruptible {
        booksRepository.findById(id) ?: throw BookNotFoundException(id)
    }

    private suspend fun fetchReviewsFor(id: Long) = runInterruptible {
        reviewsService.fetchReviewsFor(id)
    }
}

And calling the endpoint (happy path) would produce the following logs:

10:50:07.596 [DefaultDispatcher-worker-1] [] INFO  c.b.b.BooksController - [START] 3
10:50:07.599 [DefaultDispatcher-worker-2] [] INFO  c.b.r.ReviewsService - [START] Fetching reviews for book with id 3
10:50:07.599 [DefaultDispatcher-worker-3] [] INFO  c.b.b.BooksRepository - [START] Fetching book with id 3
10:50:08.604 [DefaultDispatcher-worker-2] [] INFO  c.b.r.ReviewsService - [DONE] Fetched reviews for book with id 3
10:50:08.632 [DefaultDispatcher-worker-3] [] INFO  c.b.b.BooksRepository - [DONE] Fetched book with id 3
10:50:08.633 [DefaultDispatcher-worker-3] [] INFO  c.b.b.BooksController - [SUCCESS] Returning 3

And the logs before we introduced structured concurrency:

10:51:22.063 [tomcat-handler-0] [requestId=djm] INFO  c.b.b.BooksController - [START] 3
10:51:22.064 [tomcat-handler-0] [requestId=djm] INFO  c.b.b.BooksRepository - [START] Fetching book with id 3
10:51:23.086 [tomcat-handler-0] [requestId=djm] INFO  c.b.b.BooksRepository - [DONE] Fetched book with id 3
10:51:23.086 [tomcat-handler-0] [requestId=djm] INFO  c.b.r.ReviewsService - [START] Fetching reviews for book with id 3
10:51:24.093 [tomcat-handler-0] [requestId=djm] INFO  c.b.r.ReviewsService - [DONE] Fetched reviews for book with id 3
10:51:24.094 [tomcat-handler-0] [requestId=djm] INFO  c.b.b.BooksController - [SUCCESS] Returning 3

A few things that were excluded in the previous parts of the series are the thread id ([tomcat-handler-0] or [DefaultDispatcher-worker-1]) and the [requestId=djm].

Comparing the logs from before and after introducing structured concurrency, we can notice that [requestId=djm] disappeared.

To understand why this happened, we need to take a look into the implementation.

Servlet Filter and MDC

A feature of our app that we didn't show so far is that it adds a unique request id to each request. This is achieved by implementing jakarta.servlet.Filter:

private const val REQUEST_ID_KEY = "requestId"

@Component
class RequestIdFilter : Filter {

    override fun doFilter(
        request: ServletRequest,
        response: ServletResponse,
        filterChain: FilterChain,
    ) {
        val requestId = generateRequestId()
        MDC.put(REQUEST_ID_KEY, requestId)
        filterChain.doFilter(request, response)
    }
}

We are using Logback for logging and MDC is a way to have some additional context with each log statement. The implementation of MDC is using ThreadLocal under the hood, we'll see a bit later why this is important.

Thanks to this RequestIdFilter, we get this requestId in our logs:

10:51:22.063 [tomcat-handler-0] [requestId=djm] INFO  c.b.b.BooksController - [START] 3

It won't show up there automatically however, we have to configure it in logback.xml (%X):

<pattern>%d{HH:mm:ss.SSS} [%thread] [%X] %-5level %logger{12} - %msg%n</pattern>

But where did it disappear?

After introducing structured concurrency with coroutines, our logs look like this:

10:50:07.596 [DefaultDispatcher-worker-1] [] INFO  c.b.b.BooksController - [START] 3

The [requestId=djm] part is gone.

As mentioned above, the implementation of MDC is using ThreadLocal as a storage, but when using coroutines, thread switching can happen whenever a suspension point is reached. Once the thread is switched, the MDC is empty.

There's an easy way to fix this, but it's important to understand why it's happening in the first place.

Because it's a common problem and a lot of people use MDC, there is an official library that can help us:

implementation("org.jetbrains.kotlinx:kotlinx-coroutines-slf4j:$coroutinesVersion")

In order to utilize it, all we have to do is add it to runBlocking:

import kotlinx.coroutines.slf4j.MDCContext
...
@GetMapping("/{id}")
fun fetchBook(@PathVariable id: Long): Book = runBlocking(Dispatchers.IO + MDCContext()) { ...

After adding this, here's how our logs look like:

11:08:32.406 [DefaultDispatcher-worker-1] [requestId=wor] INFO  c.b.b.BooksController - [START] 3
11:08:32.409 [DefaultDispatcher-worker-2] [requestId=wor] INFO  c.b.r.ReviewsService - [START] Fetching reviews for book with id 3
11:08:32.409 [DefaultDispatcher-worker-3] [requestId=wor] INFO  c.b.b.BooksRepository - [START] Fetching book with id 3
11:08:33.416 [DefaultDispatcher-worker-2] [requestId=wor] INFO  c.b.r.ReviewsService - [DONE] Fetched reviews for book with id 3
11:08:33.445 [DefaultDispatcher-worker-3] [requestId=wor] INFO  c.b.b.BooksRepository - [DONE] Fetched book with id 3
11:08:33.446 [DefaultDispatcher-worker-3] [requestId=wor] INFO  c.b.b.BooksController - [SUCCESS] Returning 3

This seems like a lot. Is there a better way?

Java is (slowly) introducing a new API for structured concurrency: StructuredTaskScope that looks promising and can also help us solve the problem we've so far solved with kotlin coroutines.

Read about it in the next part.

Structured Concurrency in Practice: CoroutineScope vs StructuredTaskScope [Part 2]

Filip Egeric — Sun, 29 Mar 2026 18:44:03 +0000

This post series assumes familiarity with Kotlin, Java, and Spring Boot.

No AI was used during the writing of this post series.

What about errors?

In Part 1 we managed to reduce the load time of our endpoint from 2s to 1s, but we only covered the happy path. In this part, we'll see what happens when things go wrong.

As a reminder, here's our example:

@GetMapping("/{id}")
fun fetchBook(@PathVariable id: Long): Book = runBlocking(Dispatchers.IO) {
    log.info("[START] $id")

    val book = async { findBook(id) }
    val reviews = async { fetchReviewsFor(id) }

    book.await()
        .copy(reviews = reviews.await())
        .also { log.info("[SUCCESS] Returning ${it.id}") }
}

What if we can't fetch the reviews

The reviews service is a 3rd party service and we have no control over it. What happens if this service becomes unavailable or starts returning bad results? We can simulate that in our code and see what happens:

// application.properties
...
reviews-service.fail=true
...

And the calling the endpoint:

➜  ~ curl -s -w '\n\nTotal time: %{time_total}s\n' 'http://localhost:9999/books/3'
{"timestamp":"2026-03-29T06:33:41.178Z","status":500,"error":"Internal Server Error","trace":"java.lang.RuntimeException: Something went wrong when fetching reviews...","message":"Something went wrong when fetching reviews","path":"/books/3"}

Total time: 1.177979s

We get an error, and it still takes about 1s.
It kind of works, but what is worse than receiving an error?

Waiting for a long time and then receiving an error

We can simulate this situation as well:

// application.properties
books-repository.delay-in-seconds=3
reviews-service.delay-in-seconds=1
reviews-service.fail=true

Calling the endpoint:

➜  ~ curl -s -w '\n\nTotal time: %{time_total}s\n' 'http://localhost:9999/books/3'
{"timestamp":"2026-03-29T06:37:35.415Z","status":500,"error":"Internal Server Error","trace":"java.lang.RuntimeException: Something went wrong when fetching reviews...","message":"Something went wrong when fetching reviews","path":"/books/3"}

Total time: 3.179492s

We get the same error, but now after 3s :(

Why is this really bad?

The reviews service fails after one second, but we still wait for 2 more seconds for the book to be loaded from the database. Even after just one second, we know that we won't be able to return a success response, yet we still wait for 2 more seconds before returning an error.

How should it work?

It would make sense that as soon as one of the calls fails, we return an error to the client and cancel the other call. And reading through the documentation for coroutines, we see that this should happen by default:

Composing suspending functions | Kotlin Documentation

kotlinlang.org

Why doesn't it work exactly?

The problem in our example is that we are mixing blocking and non-blocking code. When fetchReviews fails it propagates the cancellation to the parent scope and then the parent scope tries to cancel all the other children (in this case findBook). But findBook is a blocking call that has no concept of "Cancellation", it cannot be cancelled, it can only be interrupted.

This is why we have to be especially careful when mixing blocking and non-blocking code. Here's our findBook method so far:

private fun findBook(id: Long) =
    booksRepository.findById(id) ?: throw BookNotFoundException(id)

We can try to just add a suspend modifier to it, but that alone won't help much. What we also have to do is wrap it in runInterruptible:

private suspend fun findBook(id: Long) = runInterruptible {
    booksRepository.findById(id) ?: throw BookNotFoundException(id)
}

To understand why, we can read about it here.

Did we fix it?

Calling the endpoint again:

➜  ~ curl -s -w '\n\nTotal time: %{time_total}s\n' 'http://localhost:9999/books/3'
{"timestamp":"2026-03-29T06:54:25.389Z","status":500,"error":"Internal Server Error","trace":"java.lang.RuntimeException: Something went wrong when fetching reviews...","message":"Something went wrong when fetching reviews","path":"/books/3"}

Total time: 1.176844s

We get the same exception, but now after only a second!

And if we check the logs:

08:54:24.347 ... BooksController - [START] 3
08:54:24.349 ... ReviewsService - [START] Fetching reviews for book with id 3
08:54:24.350 ... BooksRepository - [START] Fetching book with id 3
08:54:25.373 ... ERROR o.a.c.c.C.[.[.[.[dispatcherServlet] - Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed: java.lang.RuntimeException: Something went wrong when fetching reviews] ...

We see that we start fetching the book from the repository, but we don't see that we wait for it to finish, which means that it's successfully cancelled.

We of course need to do the same thing for fetchReviewsFor(id):

private suspend fun fetchReviewsFor(id: Long) = runInterruptible {
    reviewsService.fetchReviewsFor(id)
}

After all these changes, here's how our code looks now:

@GetMapping("/{id}")
fun fetchBook(@PathVariable id: Long): Book = runBlocking(Dispatchers.IO) {
    log.info("[START] $id")

    val book = async { findBook(id) }
    val reviews = async { fetchReviewsFor(id) }

    book.await()
        .copy(reviews = reviews.await())
        .also { log.info("[SUCCESS] Returning ${it.id}") }
}

private suspend fun findBook(id: Long) = runInterruptible {
    booksRepository.findById(id) ?: throw BookNotFoundException(id)
}

private suspend fun fetchReviewsFor(id: Long) = runInterruptible {
    reviewsService.fetchReviewsFor(id)
}

Is that all?

If you read carefully, you noticed that I left out some parts of the logs (by replacing them with ...):

07:32:51.494 ... BooksController - [START] 5
07:32:51.494 ... BooksRepository - [START] Fetching book with id 5
07:32:52.501 ... BooksRepository - [DONE] Fetched book with id 5
07:32:52.502 ... ReviewsService - [START] Fetching reviews for book with id 5
07:32:53.506 ... ReviewsService - [DONE] Fetched reviews for book with id 5
07:32:53.506 ... BooksController - [SUCCESS] Returning 5

You can find out what's behind those 3 dots and why is it important in the next part.

Structured Concurrency in Practice: CoroutineScope vs StructuredTaskScope [Part 1]

Filip Egeric — Sun, 29 Mar 2026 18:43:41 +0000

This post series assumes familiarity with Kotlin, Java, and Spring Boot.

No AI was used during the writing of this post series.

What we're building

We have an old library and we want to sell all the books. For that purpose we decided to build a simple bookstore app. We decide to use the best tools for the job, which in this case are Kotlin and Spring Boot.

We want our customers to be able to see the details of each book, along with the reviews. For that we have the following controller:

package com.bookstore.books

import com.bookstore.reviews.ReviewsService
import org.slf4j.LoggerFactory
import org.springframework.web.bind.annotation.GetMapping
import org.springframework.web.bind.annotation.PathVariable
import org.springframework.web.bind.annotation.RequestMapping
import org.springframework.web.bind.annotation.RestController

@RestController
@RequestMapping("/books")
class BooksController(
    private val booksRepository: BooksRepository,
    private val reviewsService: ReviewsService,
) {
    private val log = LoggerFactory.getLogger(BooksController::class.java)

    @GetMapping("/{id}")
    fun fetchBook(@PathVariable id: Long): Book {
        log.info("[START] $id")

        val book = findBook(id)
        val reviews = fetchReviewsFor(id)

        return book
            .copy(reviews = reviews)
            .also { log.info("[SUCCESS] Returning ${it.id}") }
    }

    private fun findBook(id: Long) =
        booksRepository.findById(id) ?: throw BookNotFoundException(id)

    private fun fetchReviewsFor(id: Long) =
        reviewsService.fetchReviewsFor(id)
}

The fetchBook method is quite straightforward: We find the book in the database, fetch the reviews for it from a 3rd party service, and finally return the book together with the reviews.

After trying it out, we see that the response time for this endpoint is somewhat slow. When calling the endpoint multiple times, we see that the response times are consistently around 2s:

➜  ~ curl -s -w '\n\nTotal time: %{time_total}s\n' 'http://localhost:9999/books/5'
{"id":5,"title":"One Hundred Years of Solitude","author":"Gabriel García Márquez","reviews":[{"rating":5,"description":"This book is awesome!"},{"rating":4,"description":"This book is pretty good, but could be better"},{"rating":3,"description":"I don't like this book at all"},{"rating":1,"description":"This book sucks, I've given it a 1/5"}]}

Total time: 2.022749s
➜  ~ curl -s -w '\n\nTotal time: %{time_total}s\n' 'http://localhost:9999/books/7'
{"id":7,"title":"The Hobbit","author":"J.R.R. Tolkien","reviews":[{"rating":5,"description":"This book is awesome!"},{"rating":4,"description":"This book is pretty good, but could be better"},{"rating":3,"description":"I don't like this book at all"},{"rating":1,"description":"This book sucks, I've given it a 1/5"}]}

Total time: 2.026064s
➜  ~ curl -s -w '\n\nTotal time: %{time_total}s\n' 'http://localhost:9999/books/1'
{"id":1,"title":"To Kill a Mockingbird","author":"Harper Lee","reviews":[{"rating":5,"description":"This book is awesome!"},{"rating":4,"description":"This book is pretty good, but could be better"},{"rating":3,"description":"I don't like this book at all"},{"rating":1,"description":"This book sucks, I've given it a 1/5"}]}

Total time: 2.020895s
➜  ~ curl -s -w '\n\nTotal time: %{time_total}s\n' 'http://localhost:9999/books/3'
{"id":3,"title":"Pride and Prejudice","author":"Jane Austen","reviews":[{"rating":5,"description":"This book is awesome!"},{"rating":4,"description":"This book is pretty good, but could be better"},{"rating":3,"description":"I don't like this book at all"},{"rating":1,"description":"This book sucks, I've given it a 1/5"}]}

Total time: 2.018304s

And the logs show the following:

07:32:51.494 ... BooksController - [START] 5
07:32:51.494 ... BooksRepository - [START] Fetching book with id 5
07:32:52.501 ... BooksRepository - [DONE] Fetched book with id 5
07:32:52.502 ... ReviewsService - [START] Fetching reviews for book with id 5
07:32:53.506 ... ReviewsService - [DONE] Fetched reviews for book with id 5
07:32:53.506 ... BooksController - [SUCCESS] Returning 5

From the logs, it's obvious that it takes about 1s to find the book in the database and only after that we start fetching the reviews, which also takes around 1s, adding up to 2s in total.

Making it faster

Zooming in at the code, we see that the 2 calls we make (one to the database and the other to the reviews service) are completely independent:

@GetMapping("/{id}")
fun fetchBook(@PathVariable id: Long): Book {
    log.info("[START] $id")

    val book = findBook(id)
    val reviews = fetchReviewsFor(id)

    return book
        .copy(reviews = reviews)
        .also { log.info("[SUCCESS] Returning ${it.id}") }
}

This means that there is no reason for them to be sequential, they can be executed in parallel.
Since we are using Kotlin, if we google or ask an AI (Accelerated Inference) tool the following: "How to make 2 calls in parallel in Kotlin", the first answer will most likely be: "Use coroutineScope and async coroutine builders."

After implementing it (or letting AI do it), our code looks like this:

@GetMapping("/{id}")
suspend fun fetchBook(@PathVariable id: Long): Book = coroutineScope {
    log.info("[START] $id")

    val book = async { findBook(id) }
    val reviews = async { fetchReviewsFor(id) }

    book.await()
        .copy(reviews = reviews.await())
        .also { log.info("[SUCCESS] Returning ${it.id}") }
}

However, this doesn't compile. To understand why, we have to look at build.gradle.kts:

dependencies {
    implementation("org.springframework.boot:spring-boot-starter-webmvc")
    implementation("com.fasterxml.jackson.module:jackson-module-kotlin")
    implementation("org.jetbrains.kotlin:kotlin-reflect")
    implementation("org.springframework.boot:spring-boot-starter-data-jdbc")
// ... more dependencies
}

From the dependecies block, we see that we are using webmvc and jdbc. This means that we are using the blocking style of Spring boot, which doesn't include coroutines by default. In order to have access to coroutines, we would have to switch from webmvc to webflux. But this would mean a complete paradigm change and rewriting most of the codebase to make it non-blocking (using r2dbc instead of jdbc for example).

Since we just want to add coroutine support and we don't want to rewrite anything, the easy option is to explicitly add coroutines to our build.gradle.kts:

dependencies {
    // ...
    val coroutinesVersion = "1.10.2"
    implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:$coroutinesVersion")
    // ...
}

Now the code compiles, so we can try to run it:

➜  ~ curl -s -w '\n\nTotal time: %{time_total}s\n' 'http://localhost:9999/books/3'
{"timestamp":"2026-03-29T05:56:55.398Z","status":500,"error":"Internal Server Error","trace":"java.lang.NoClassDefFoundError: org/reactivestreams/Publisher\n\tat org.springframework.web.method.support.InvocableHandlerMethod.invokeSuspendingFunction(InvocableHandlerMethod.java:294)...

Oops, that did not work. :(

Looking at the stacktrace, we sse that we are missing org/reactivestreams/Publisher class. This class comes included if we use webflux, but since we are using webmvc the class is not there.

Digging a little deeper, we find that the reason this is happening is because we used suspend modifier on a handler method in a controller. Spring boot has first-class support for coroutines and we can mark handler methods with suspend, but it assumes usage of webflux underneath the hood in this case.

But we are using webmvc which is blocking, so why not just block:

@GetMapping("/{id}")
fun fetchBook(@PathVariable id: Long): Book = runBlocking {
    log.info("[START] $id")

    val book = async { findBook(id) }
    val reviews = async { fetchReviewsFor(id) }

    book.await()
        .copy(reviews = reviews.await())
        .also { log.info("[SUCCESS] Returning ${it.id}") }
}

We removed the suspend modifier and replaced coroutineScope {... with runBlocking {....

It's usually not recommended to use runBlocking outside of the main method or tests, but in this case we find it acceptable, because the context in which we are running is already blocking, so we are not blocking any threads that we are not supposed to block. If we were using webflux instead, then runBlocking would be a big no-no.

Now we can call the endpoint again:

➜  ~ curl -s -w '\n\nTotal time: %{time_total}s\n' 'http://localhost:9999/books/3'
{"id":3,"title":"Pride and Prejudice","author":"Jane Austen","reviews":[{"rating":5,"description":"This book is awesome!"},{"rating":4,"description":"This book is pretty good, but could be better"},{"rating":3,"description":"I don't like this book at all"},{"rating":1,"description":"This book sucks, I've given it a 1/5"}]}

Total time: 2.206648s

It works, but it still takes 2s :(

To understand why, we have to understand how coroutines and runBlocking work. Here's the (important parts of) docs for runBlocking:

Runs a new coroutine and **blocks** the current thread _interruptibly_ until its completion.
...
The default [CoroutineDispatcher] for this builder is an internal implementation of event loop that processes continuations
in this blocked thread until the completion of this coroutine.
See [CoroutineDispatcher] for the other implementations that are provided by `kotlinx.coroutines`.
...

It turns out, that the reason we are not executing anything in parallel, is because the default dispatcher for runBlocking is executing all the coroutines on a single calling thread. Luckily, the fix for this is easy, we just need to add a different dispatcher to runBlocking:

@GetMapping("/{id}")
fun fetchBook(@PathVariable id: Long): Book = runBlocking(Dispatchers.IO) { ...

Calling the endpoint again:

➜  ~ curl -s -w '\n\nTotal time: %{time_total}s\n' 'http://localhost:9999/books/3'
{"id":3,"title":"Pride and Prejudice","author":"Jane Austen","reviews":[{"rating":5,"description":"This book is awesome!"},{"rating":4,"description":"This book is pretty good, but could be better"},{"rating":3,"description":"I don't like this book at all"},{"rating":1,"description":"This book sucks, I've given it a 1/5"}]}

Total time: 1.186013s

It now returns in about 1s!

Mission accomplished, right?

Well, if we vibe coded the entire thing, we can just put it to rest, because the happy path works. However, if we don't want to be woken up at 2am by alerts from production, we may want to dig a little deeper.

That digging will happen in part 2.

Why don't we pass child components as props?

Filip Egeric — Thu, 08 Aug 2024 18:35:13 +0000

Even though the title of this article suggests that it will be about React and front-end, we'll actually start from the other side.

How it's usually done in the back-end

Let's take a look at the following piece of code:

class UserService {

  register(request: RegisterRequest) {
    // TODO
  }

}

In the register method we would most likely validate the request create a new user and then save it to the database. Let's focus on the saving to the database part. Here is what that would look like:

class UserService {

  constructor(private database: Database) {}

  register(request: RegisterRequest) {
    // validate and process request
    this.database.executeQuery("INSERT INTO users VALUES (...)")
  }

}

Normally the database is injected through the constructor and it would be an interface:

interface Database {
  executeQuery(query: string): Row[]
}

And there would be (at least one) implementation of that interface:

import { MySqlClient, MySqlResult } from 'some-mysql-package'

class MySqlDatabase implements Database {

  constructor(private mysql: MySqlClient) {}

  executeQuery(query: string): Row[] {
    const result = this.mysql.query(query)
    return this.rowsFrom(result)
  }

  private rowsFrom(result: MySqlResult): Row[] {
    // ...
  }
}

Now the reason for abstracting the database in this way is easier testing and weaker coupling with a specific implementation. So if we ever wanted to replace mysql with postgres, we wouldn't have to touch (change any code in) UserService. Instead we would just add another implementation of the Database interface and use it.

import { PgClient, PgResult } from 'pg-database-package'

class PgDatabase implements Database {

  constructor(private pg: PgClient) {}

  executeQuery(query: string): Row[] {
    const result = this.pg.execute(query)
    return this.rowsFrom(result)
  }

  private rowsFrom(result: PgResult): Row[] {
    // ...
  }
}

Now this abstraction may seem a bit unnecessary, but if we tried using some-mysql-package directly in the UserService, instead of the Database interface, it would hardly pass the code review.

There are other benefits to this approach.
What if we wanted to log each query that's being run. We could do something like this:

class LoggingDatabase implements Database {

  constructor(private actualDatabase: Database) {}

  executeQuery(query: string): Row[] {
    this.log(`Executing query: ${query}`)
    return this.actualDatabase.executeQuery(query)
  }

  private log(message: string) { ... }
}

So when the UserService is instantiated it would look like this:

new UserService(new LoggingDatabase(new MySqlDatabase(mysqlClient)))

or:

new UserService(new LoggingDatabase(new PgDatabase(pgClient)))

Patterns like this are quite common in the back-end.

But what about front-end?

Going back to the front-end and React, let's assume there is now a register form:

import { TextInput, AgeInput } from 'components'
import { register } from 'some-api'

const RegisterForm: FC = () => {
  const [email, setEmail] = useState('')
  const [password, setPassword] = useState('')
  const [age, setAge] = useState<number | null>(null)

  function register(e: SubmitEvent) {
    e.preventDefault()
    register({ email, password, age })
  }

  return (
    <form onSubmit={register}>
      <TextInput placeholder="email" onChange={setEmail} />
      <TextInput placeholder="password" onChange={setPassword} />
      <AgeInput onChange={setAge} />
      <button>Register</button>
    </form>
  )
}

And let's focus on this line:

<AgeInput onChange={setAge} />

From the perspective of RegisterForm component, it is not important how the AgeInput is implemented. The only thing that's important is that it accepts a prop onChange of type (age: number) => void.

So let's look at the possible implementations of this AgeInput component:

Number input

const AgeInput: FC<{ onChange: (age: number) => void }> = ({ onChange }) => {
  return <input type="number" onChange={e => onChange(Number(e.target.value))} />
}

Slide input

const AgeInput: FC<{ onChange: (age: number) => void }> = ({ onChange }) => {
  return <input type="range" min="0" max="120" step="1" onChange={e => onChange(Number(e.target.value))} />
}

or it could be anything else, as long as it accepts props like this:

interface AgeInputProps { 
  onChange: (age: number) => void 
}

So why aren't we injecting it instead of importing it:

import { TextInput, AgeInputProps } from 'components'
import { register } from 'some-api'

const RegisterForm: FC<{ AgeInput: FC<AgeInputProps> }> = ({ AgeInput }) => {
  const [email, setEmail] = useState('')
  const [password, setPassword] = useState('')
  const [age, setAge] = useState<number | null>(null)

  function register(e: SubmitEvent) {
    e.preventDefault()
    register({ email, password, age })
  }

  return (
    <form onSubmit={register}>
      <TextInput placeholder="email" onChange={setEmail} />
      <TextInput placeholder="password" onChange={setPassword} />
      <AgeInput onChange={setAge} />
      <button>Register</button>
    </form>
  )
}

This way we could choose which implementation to use without touching the RegisterForm and we could even implement some side effects (or maybe even interceptors) similarly to LoggingDatabase:

import { AgeInput, AgeInputProps } from 'components'

const LoggingAgeInput: FC<AgeInputProps> = (props) => {

  function onChange(age: number) {
    console.log(`Age changed to: ${age}`)
    props.onChange(age)
  }

  return (
    <AgeInput {...props} onChange={onChange} />
  )
}

So? Why don't we?

Using GraphQL DataLoaders with NestJS

Filip Egeric — Sat, 26 Jun 2021 18:49:03 +0000

This post assumes familiarity with NestJS and GraphQL.

What we will be building

In this post we will build a simple GraphQL API in NestJS that enables getting a list of posts.

We will use the following GraphQL query:

query GetPosts {
  posts {
    id
    title
    body
    createdBy {
      id
      name
    }
  }
}

Creating NestJS application

nest new example-app

This will generate a new NestJS app with the following structure:

After removing what we don't need we are left with just app.module.ts and main.ts.

Adding users module

nest g module users

After generating module we will add user.entity.ts and users.service.ts:

`user.entity.ts`

export class User {
  id: number;
  name: string;
}

`users.service.ts`

import { Injectable } from '@nestjs/common';

import { delay } from '../util';
import { User } from './user.entity';

@Injectable()
export class UsersService {
  private users: User[] = [
    { id: 1, name: 'John' },
    { id: 2, name: 'Jane' },
    { id: 3, name: 'Alex' },
    { id: 4, name: 'Anna' },
  ];

  async getUsers() {
    console.log('Getting users...');
    await delay(3000);
    return this.users;
  }
}

Before we return users in getUsers method we simulate database latency with a delay of 3000ms.

Don't forget to add UsersService to exports array in users.module.ts

Adding posts module

Here we do pretty much the same we did in users module:

`post.entity.ts`

export class Post {
  id: string;
  title: string;
  body: string;
  userId: number;
}

`posts.service.ts`

import { Injectable } from '@nestjs/common';

import { delay } from '../util';
import { Post } from './post.entity';

@Injectable()
export class PostsService {
  private posts: Post[] = [
    { id: 'post-1', title: 'Post 1', body: 'Lorem 1', userId: 1 },
    { id: 'post-2', title: 'Post 2', body: 'Lorem 2', userId: 1 },
    { id: 'post-3', title: 'Post 3', body: 'Lorem 3', userId: 2 },
  ];

  async getPosts() {
    console.log('Getting posts...');
    await delay(3000);
    return this.posts;
  }
}

That should be enough for now when it comes to core logic. Now let's add GraphQL related code.

Adding GraphQL

We will be using code first aproach.

Installing packages

npm i @nestjs/graphql graphql-tools graphql apollo-server-express

Adding `GraphQLModule` to our `AppModule`:

import { Module } from '@nestjs/common';
import { GraphQLModule } from '@nestjs/graphql';
import { join } from 'path';

import { PostsModule } from './posts/posts.module';
import { UsersModule } from './users/users.module';

@Module({
  imports: [
    UsersModule,
    PostsModule,
    GraphQLModule.forRoot({
      autoSchemaFile: join(process.cwd(), 'src/schema.gql'),
    }),
  ],
  controllers: [],
  providers: [],
})
export class AppModule {}

By declaring autoSchemaFile property NestJS will generate GraphQL schema from types we declare in code. However since we haven't declared any when we run npm run start:dev we will get an error.
We will fix that error by declaring GraphQL types in our code. In order to do that we need to add some decorators to our entity classes:

`user.entity.ts`

import { Field, Int, ObjectType } from '@nestjs/graphql';

@ObjectType()
export class User {
  @Field(() => Int)
  id: number;

  @Field()
  name: string;
}

However this doesn't solve our problem since we are still getting an error. So adding a resolver should fix it:

`users.resolver.ts`

import { Query, Resolver } from '@nestjs/graphql';

import { User } from './user.entity';
import { UsersService } from './users.service';

@Resolver(User)
export class UsersResolver {
  constructor(private readonly usersService: UsersService) {}

  @Query(() => [User])
  getUsers() {
    return this.usersService.getUsers();
  }
}

Don't forget to add UsersResolver to providers array in users.module.ts

After adding UsersResolver the error goes away and we get a new file:

`schema.gql`

# ------------------------------------------------------
# THIS FILE WAS AUTOMATICALLY GENERATED (DO NOT MODIFY)
# ------------------------------------------------------

type User {
  id: Int!
  name: String!
}

type Query {
  getUsers: [User!]!
}

So let's test it out. Open GraphQL playground (usually on http://localhost:3000/graphql) and execute the following query:

query GetUsers {
  users {
    id
    name
  }
}

So after about 3 seconds we should get the following result:

{
  "data": {
    "users": [
      {
        "id": 1,
        "name": "John"
      },
      {
        "id": 2,
        "name": "Jane"
      },
      {
        "id": 3,
        "name": "Alex"
      },
      {
        "id": 4,
        "name": "Anna"
      }
    ]
  }
}

In the same way we will add decorators and resolver for posts:

`post.entity.ts`

import { Field, ObjectType } from '@nestjs/graphql';

@ObjectType()
export class Post {
  @Field()
  id: string;

  @Field()
  title: string;

  @Field()
  body: string;

  userId: number;
}

`posts.resolver.ts`

import { Query, Resolver } from '@nestjs/graphql';

import { Post } from './post.entity';
import { PostsService } from './posts.service';

@Resolver(Post)
export class PostsResolver {
  constructor(private readonly postsService: PostsService) {}

  @Query(() => [Post], { name: 'posts' })
  getPosts() {
    return this.postsService.getPosts();
  }
}

Adding relationships

So this is what GraphQL is all about: querying connected data.

We will now add createdBy field to post.entity.ts:

`post.entity.ts`

@Field(() => User)
createdBy?: User;

After this we should be able to run GetPosts query from the beginning of this post. However we get an error:

"Cannot return null for non-nullable field Post.createdBy."

In order to fix this we need to resolve createdBy field in posts.resolver.ts. We do that by adding the following methods:

`posts.resolver.ts`

@ResolveField('createdBy', () => User)
getCreatedBy(@Parent() post: Post) {
  const { userId } = post;
  return this.usersService.getUser(userId);
}

`users.service.ts`

async getUser(id: number) {
  console.log(`Getting user with id ${id}...`);
  await delay(1000);
  return this.users.find((user) => user.id === id);
}

We also have to export UsersService from UsersModule and then import UsersModule into PostsModule.

So now we can finally go ahead and run GetPosts query and we should get the following result:

{
  "data": {
    "posts": [
      {
        "id": "post-1",
        "title": "Post 1",
        "body": "Lorem 1",
        "createdBy": {
          "id": 1,
          "name": "John"
        }
      },
      {
        "id": "post-2",
        "title": "Post 2",
        "body": "Lorem 2",
        "createdBy": {
          "id": 1,
          "name": "John"
        }
      },
      {
        "id": "post-3",
        "title": "Post 3",
        "body": "Lorem 3",
        "createdBy": {
          "id": 2,
          "name": "Jane"
        }
      }
    ]
  }
}

So that took some time because of all those delays.
However if we check the console we should see the following:

Getting posts...
Getting user with id 1...
Getting user with id 1...
Getting user with id 2...

In a real world scenario all these lines would mean a separate query to the database. That is known as N+1 problem.

What this means is that for every post that first "query" returns we would have to make a separate query for it's creator even if all posts were created by the same person (as we can see above we are getting user with id 1 twice).

This is where DataLoader can help.

What is DataLoader

According to the official documentation:

DataLoader is a generic utility to be used as part of your application's data fetching layer to provide a simplified and consistent API over various remote data sources such as databases or web services via batching and caching.

Creating users loader

First we need to install it:

npm i dataloader

`users.loader.ts`

import * as DataLoader from 'dataloader';

import { mapFromArray } from '../util';
import { User } from './user.entity';
import { UsersService } from './users.service';

function createUsersLoader(usersService: UsersService) {
  return new DataLoader<number, User>(async (ids) => {
    const users = await usersService.getUsersByIds(ids);

    const usersMap = mapFromArray(users, (user) => user.id);

    return ids.map((id) => usersMap[id]);
  });
}

Let's explain what is happening here:

DataLoader constructor accepts a batching function as an argument. A batching function takes an array of ids (or keys) and returns a promise that resolves to an array of values. Important thing to note here is that those values must be in the exact same order as ids argument.
usersMap is a simple object where keys are user ids and values are actual users:

{
  1: {id: 1, name: "John"},
  ...
}

So let's see how this can be used:

const usersLoader = createUsersLoader(usersService);

const user1 = await usersLoader.load(1)
const user2 = await usersLoader.load(2);

This will actualy make one "database request" using that batching function we defined earlier and get users 1 and 2 at the same time.

How does this help in GraphQL

The basic idea is to create new users loader on every HTTP request so it can be used in multiple resolvers. In GraphQL a single request shares the same context object between resolvers so we should be able to "attach" our users loader to context and then use it in our resolvers.

Attaching values to GraphQL context

If we were using just Apollo Server we would attach values to context in the following way:


// Constructor
const server = new ApolloServer({
  typeDefs,
  resolvers,
  context: ({ req }) => ({
    authScope: getScope(req.headers.authorization)
  })
}));

// Example resolver
(parent, args, context, info) => {
  if(context.authScope !== ADMIN) throw new AuthenticationError('not admin');
  // Proceed
}

However in our NestJS application we don't explicitly instantiate ApolloServer so the context function should be declared when declaring GraphQLModule. In our case that's in app.module.ts:

GraphQLModule.forRoot({
  autoSchemaFile: join(process.cwd(), 'src/schema.gql'),
  context: () => ({
    randomValue: Math.random(),
  }),
}),

The next thing we should do is access context inside a resolver and in @nestjs/graphql there is a decorator for that:

posts.resolver.ts

@Query(() => [Post], { name: 'posts' })
getPosts(@Context() context: any) {
  console.log(context.randomValue);
  return this.postsService.getPosts();
}

@ResolveField('createdBy', () => User)
getCreatedBy(@Parent() post: Post, @Context() context: any {
  console.log(context.randomValue);
  const { userId } = post;
  return this.usersService.getUser(userId);
}

Now when we run GetPosts query we should see the following in the console:

0.858156868751532
Getting posts...
0.858156868751532
Getting user with id 1...
0.858156868751532
Getting user with id 1...
0.858156868751532
Getting user with id 2...

It's the same value for all resolvers and to prove that it is unique to each HTTP request we can just run the query again and check if randomValue is changed.

We can make this a bit nicer by passing a string to Context decorator:

@Query(() => [Post], { name: 'posts' })
getPosts(@Context('randomValue') randomValue: number) {
  console.log(randomValue);
  return this.postsService.getPosts();
}

@ResolveField('createdBy', () => User)
getCreatedBy(@Parent() post: Post, @Context('randomValue') randomValue: number) {
  console.log(randomValue);
  const { userId } = post;
  return this.usersService.getUser(userId);
}

Now that we've seen how to attach values to GraphQL context we can proceed and try to attach data loaders to it.

Attaching DataLoaders to GraphQL context

app.module.ts

GraphQLModule.forRoot({
  autoSchemaFile: join(process.cwd(), 'src/schema.gql'),
  context: () => ({
    randomValue: Math.random(),
    usersLoader: createUsersLoader(usersService),
  }),
}),

If we just try to add usersLoader as shown above we will get an error because usersService isn't defined. To solve this we need to change the definition for GraphQLModule to use forRootAsync method:

app.module.ts

GraphQLModule.forRootAsync({
  useFactory: (usersService: UsersService) => ({
    autoSchemaFile: join(process.cwd(), 'src/schema.gql'),
    context: () => ({
      randomValue: Math.random(),
      usersLoader: createUsersLoader(usersService),
    }),
  }),
}),

Now this may compile, but still won't actually work. We need to add inject property bellow useFactory:

useFactory: ...,
inject: [UsersService],

This will now throw an error so we need to somehow provide UsersService to GraphQLModule and we do that by importing UsersModule into GraphQLModule.

imports: [UsersModule],
useFactory: ...

With that we have now successfully attached usersLoader to GraphQL context object. Let's now see how to use it.

Using `usersLoader` inside a resolver

We can now go ahead and replace randomValue in our resolvers with usersLoader:

posts.resolver.ts

import { Context, Parent, Query, ResolveField, Resolver } from '@nestjs/graphql';
import * as DataLoader from 'dataloader';

import { User } from '../users/user.entity';
import { Post } from './post.entity';
import { PostsService } from './posts.service';

@Resolver(Post)
export class PostsResolver {
  constructor(private readonly postsService: PostsService) {}

  @Query(() => [Post], { name: 'posts' })
  getPosts() {
    return this.postsService.getPosts();
  }

  @ResolveField('createdBy', () => User)
  getCreatedBy(
    @Parent() post: Post,
    @Context('usersLoader') usersLoader: DataLoader<number, User>,
  ) {
    const { userId } = post;
    return usersLoader.load(userId);
  }
}

Now when we run GetPosts query the console output should look like this:

Getting posts...
Getting users with ids (1,2)

In a real world scenario this would mean just 2 database queries no matter the number of posts or users and that is how we solved the N+1 problem.

Conclusion

All this setup is a bit complex but the good thing is that it only needs to be done once and after that we can just add more loaders and use them in resolvers.

Full code is available on GitHub:
https://github.com/filipegeric/nestjs-graphql-dataloaders

Thanks for reading! :)

DEV Community: Filip Egeric

Structured Concurrency in Practice: CoroutineScope vs StructuredTaskScope [Part 5]

CoroutineScope vs StructuredTaskScope: Which one to choose?

CoroutineScope

StructuredTaskScope

When to use CoroutineScope and why?

When to NOT use CoroutineScope and why?

When to use StructuredTaskScope

When NOT to use StructuredTaskScope

Conclusion

Structured Concurrency in Practice: CoroutineScope vs StructuredTaskScope [Part 4]

Coroutines are an all-in feature

All we wanted was 2 calls in parallel

StructuredTaskScope

Seeing it in action

Sad path

That was easy, right?

Hoops

Kotlin flexibility at its best

What about that lost requestId?

CoroutineScope vs StructuredTaskScope: Which one to choose?

Structured Concurrency in Practice: CoroutineScope vs StructuredTaskScope [Part 3]

What happened to our logs?

Servlet Filter and MDC

But where did it disappear?

This seems like a lot. Is there a better way?

Structured Concurrency in Practice: CoroutineScope vs StructuredTaskScope [Part 2]

What about errors?

What if we can't fetch the reviews

Why is this really bad?

How should it work?

Composing suspending functions | Kotlin Documentation

Why doesn't it work exactly?

Did we fix it?

Is that all?

Structured Concurrency in Practice: CoroutineScope vs StructuredTaskScope [Part 1]

What we're building

Making it faster

Mission accomplished, right?

Why don't we pass child components as props?

How it's usually done in the back-end

But what about front-end?

Using GraphQL DataLoaders with NestJS

What we will be building

Creating NestJS application

Adding users module

user.entity.ts

users.service.ts

Adding posts module

post.entity.ts

posts.service.ts

Adding GraphQL

Installing packages

Adding GraphQLModule to our AppModule:

user.entity.ts

users.resolver.ts

schema.gql

post.entity.ts

posts.resolver.ts

Adding relationships

post.entity.ts

posts.resolver.ts

users.service.ts

What is DataLoader

Creating users loader

users.loader.ts

How does this help in GraphQL

Attaching values to GraphQL context

Attaching DataLoaders to GraphQL context

Using usersLoader inside a resolver

Conclusion

What about that lost `requestId`?

`user.entity.ts`

`users.service.ts`

`post.entity.ts`

`posts.service.ts`

Adding `GraphQLModule` to our `AppModule`:

`user.entity.ts`

`users.resolver.ts`

`schema.gql`

`post.entity.ts`

`posts.resolver.ts`

`post.entity.ts`

`posts.resolver.ts`

`users.service.ts`

`users.loader.ts`

Using `usersLoader` inside a resolver