How can I use `IO` with Spring-boot for asynchrono...
# arrow
g
How can I use
IO
with Spring-boot for asynchronous servlets, just like returning a
CompletableFuture
from a REST Controller in Spring-boot?
p
the question is too general and I'm not familiar with Spring
could you please add some code to the question? maybe I can get an idea
b
async Spring Boot uses Reactor, which IIRC has controller method responses of
Mono<A>
or
Flux<A>
(single A or stream of A responses, respectively)
g
@Bob Glamm I am not speaking about async non-blocking
b
How can I use
IO
with Spring-boot for asynchronous servlets
Which part of that is not speaking about async non-blocking
g
Something that look like this
Copy code
@PostMapping("/add-book")
    public CompletableFuture<CatalogueBookResponse> addBookToCatalogue(@Valid @RequestBody AddBookToCatalogueRequest addBookToCatalogueRequest) {
b
oh you just need the Future bridge, not the Reactor bridge
g
yes
I can think of
Copy code
CompletableFuture
                .supplyAsync(() -> IO.unsafeRunSync)
in return
at the controller
I think Spring understands CompletableFuture and this is the only way I can think of converting IO to CompletableFuture at the controller
b
That's probably the cleanest approach
unless there is a way to make a global response converter from
IO<A>
->
CompletableFuture<A>
then all your controllers could just return
IO
g
Yes, that way my question, if there is any such way from the arrow library
b
That would be something exposed by Spring Boot, not Arrow
g
hmm ya
b
HttpMessageConverter
, maybe, but I'm not sure if more than one of those get called per controller
e.g. cleanest is
IO<A>
->
CompletableFuture<A>
-> some external representation of
A
, like JSON
ideally that is two converters, but I do not know if Spring will apply two converters in succession
but there must be some filter or response-type handling mechanism.. hmm.
g
Hm I shall look into it, thanks @Bob Glamm
s
Afik you could also go with Coroutines support. IO has a
suspended
method to convert to Coroutines
b
Now that I think about it, an extension function on
IO
that converts it to
CompletableFuture
would likely be preferable over a filter or interceptor or converter that converts IO -> CompletableFuture
h
We at work, for returning scala Future created own return value handler like:
Copy code
class ScalaFutureHandler(timeoutMillis: Long)(implicit ec: ExecutionContext)
    extends AsyncHandlerMethodReturnValueHandler {
And overriten 3 methods:
Copy code
isAsyncReturnValue
supportsReturnType
handleReturnValue
This allowed us to return
Future[A]
Maybe you can do something like this, but for IO?