Example you used when NOT to use RxJava is a very bad one

[thekalinga]

You mentioned here that people should not use this

.switchMap(it -> serverApi.login(name, password)
    .switchMap(loginResult -> serverApi.requestChatToken(loginResult.loginToken)
        .switchMap(chatToken -> serverApi.doOtherThingsAfter(chatToken))))

but instead use this

LoginResult loginResult = serverApi.login(name, password);
String chatToken = serverApi.requestChatToken(loginResult.loginToken);
return serverApi.doOtherThingsAfter(chatToken);

This is the classic usecase for USING RxJava, NOT avoiding it. The network is inherently asynchronous & your blocking recommendation is a terrible suggestion as each API call blocks the thread that its run in

RxJava can use network backpressure to request only the set of details you need without actually blocking any thread thru non blocking IO & without paying thread switching cost if you use RxJava variant. So your example is completely counter productive

[konmik]

There is no need to add asynchronous semantic where you need to do things sequentially.

[thekalinga]

@konmik What do you mean sequential? Ofcourse all downstream signals happen sequentially even if the upstream is asynchronous, unless explicitly stated otherwise (Reactive streams spec dictates it). So, not sure whats the point of using RxJava if all one needs is bunch of synchronous method calls

Still your recommendation is flawed

[konmik]

You're right, there is no point, that's what the article is about,