hey @isanchez,
I’ll try to build on michael’s answer and address your last question.
As was said, the point of going async is to have as few wasted time and resources as possible. When you do synchronous query and response, you are effectively doing nothing between firing the request and receiving a response.
In async mode, this chunk of time can be used to do further processing, for example reacting to the response of a previous asynchronous query.
Using the basic sync operations directly on the Bucket is equivalent to the first situation. Fully using the AsyncBucket obtained via Bucket.async() is equivalent to the second situation.
In fact, the simple sync bucket uses the AsyncBucket under the hood, blocking on each operation.
Just doing a toBlocking().last() (for instance) at the end of an async stream with flatmaps and multiple key processing, etc… should only be slightly underperforming, because the multiple requests are still processed asynchronously on the io thread. There’s still a price to pay, but chances are your application is not fully made to be asynchronous so it can be a good compromise.
If you are still designing the app, going fully reactive would rip the most benefits. You can have a look at the Reactive Manifesto : www.reactivemanifesto.org. It describes an approach for highly efficient and resilient applications, and RxJava fits well into it.
Main takeaway point though: never mix blocking behavior inside an asynchronous processing stream (be it either calls to the sdk blocking API or any other long running call). This will lead to race conditions and unexpected errors.
I hope you enjoy coding with RxJava and the new SDK!
Simon