I’m curious though, are you sure you need the full complexity of
Subscriber ? Any reason a simple loop, or a callback passed to a method implementing the loop, is not enough?
I like the API with onError, onNext and onSuccess and i like the backpressure
request(amount) from Reactor. I think the error handling of the whole chain would be more clear to other developers.
Yes Callback will also work but i think i’d also have to add the onError and the onSuccess and onFinally callback anyway.
I don’t need the Reactive (at no time blocking) features. Just call async jobs to return to the user early at the places i want. At other places I’d rather want to wait for the result. I think it would be quite readable with the subscribeOn() in my Code.
Ok so here is some prose-code I think of to build my processing/exporting code that will be used in different contexts (async, synchronous, export as excel, export as csv). Please anybody that reads this do not copy it! I’m new to Flux/Reactive/Publishers and i heavily reduced/changed my working prototype code to this
// Create REST-Entity for API Users that shows the percentage
// create a tempfile to writeto
// todo: wrap all the following in some kind of second subsciber
.doOnNext(v -> // update user facing percentage)
.doOnSuccess(v -> // transfer exported file to database )
.doOnError(e -> // set exportjob as failed)
.doFinally(type -> // delete tempfiles)
.subscribeOn(Schedulers.boundedElastic()) // run async
Maybe at some other place in code without the user facing percentage info
.map(HibernateReactive::load) // edit: this is how id imagine a high level hibernate reactive integration ignoring all the problems of batch fetching but maybe this one could handle it inside by grouping 10 ids or something like that
At a third place with jpa (or rest client or whatever) but not Hibernate Search: