How to implement blocking code in a non blocking rest resource?

[cwansart]

After reading extensive documentation, I would like to know the best way to implement the following scenario:

We need a REST interface that accesses both a database and a file system in a blocking manner. There are also other requests, which are typically simple and operate in a non-blocking manner.

I am seeking advice on how to best handle requests that involve databases and files and consequently take longer to process. Should the REST interface operate in a non-blocking manner running on an IO thread (using virtual threads, uni, multi), or should it run on a worker thread directly and being blocking?
Alternatively, would it make more sense to make the REST interface non-blocking and dispatching the IO intense work into a worker thread -- although I am not sure how to do that, yet.

An example would be a file upload and download which handles big files:

1. @Path("/{fileName}") @GET public File getFile(@RestPath("fileName") String fileName)
2. @Path("/{fileName}") @GET public Uni<AsyncFile> getFile(@RestPath("fileName") String fileName)

Alternatively wrapping File and AsyncFile in a Response object.

[cescoffier]

I would start with blocking / worker thread. If the performance and concurrency are enough, you can stop here.

If the two blocking operations can be done concurrently, using virtual threads or Mutiny will help reduce the duration of the operation.

[cwansart]

So I just keep the first signature? Due to the File return type it should run in a worker thread, right?

We have another method for a file upload which could be done concurrently, they always write new files, never overwrite existing ones. I guess that could work with virtual threads or Mutiny but reading file can happen on the same file.

How would you implement a file download? I am currently just returning a File object but I am unsure if this will clog the memory. I was wondering if returning an AsnycFile using vertx.fileSystem would be better.