Support for non-blocking code in filters and decorators

[FeldrinH]

As far as I can tell it is currently not possible to make a non-blocking request in a filter or decorator (https://jooby.io/#responses-nonblocking-limitations). Are there any plans to lift this limitation?

Decorators are very useful to extract for example authorization and authentication logic, but authentication logic often requires making a request to a database or another service to check session info and permissions. If those requests are non-blocking, such as for example Kotlin coroutines, then there is no way to take advantage of that in a filter or decorator.

This means that there is currently an incentive to just not use one of the core features of Jooby if you are using non-blocking libraries for request handling, which is a shame.

[jknack]

how would you do it? I mean built a pipeline that works for most common execution (today) and also non-blocking?

Simplicity in Jooby is a key concept. That is why is designed this way. If some one need more non-blocking support, they usually do:

{
   use(next -> ctx -> {
       // This can block
   });
   ...
   get("/reactive", ctx -> {
    // reactive library of your choice and dispatch to another thread.
    return CompletableFuture...
  });
}

This means that there is currently an incentive to just not use one of the core features of Jooby

I don't want to end up maintaining filter/decorator for all possible reactive libraries (rx, reactor, mutiny, etc). That is why I recommend to either or apply the pattern that I described before or some how write your own pipeline with a reactive filter is your desire is to do "full" reactive/non-blocking.

such as for example Kotlin coroutines:

Coroutines changed in 3.x and filter/decorator works (or should works) as expected.

[FeldrinH]

{
   use(next -> ctx -> {
       // This can block
   });
   ...
   get("/reactive", ctx -> {
    // reactive library of your choice and dispatch to another thread.
    return CompletableFuture...
  });
}

That is why I recommend to either or apply the pattern that I described before ...

I feel like I'm missing something. I want to run non-blocking code inside the block passed to use. In your example the code inside use is completely blocking is it not? So how does applying this pattern help in this case.

[jknack]

I probably get your question wrong. Nothing stop you from making a non-blocking call from filter/decorator. The line in docs:

While writing non-blocking/reactive responses we should avoid the use of Jooby filters: before and after.

It is more like a general advice mostly bc a good number of Filter (like the one that access to database: jdbi, ebean, hibernate) are blocking filter and there is no simply way to adapt those filters to be non-blocking.

better now?