4 ms·
> Also, using the HTTP handler's thread to process business logic _blocks that thread_ and makes it unavailable until the logic is done running - which could ta
by an_opabinia 5y ago
> Also, using the HTTP handler's thread to process business logic _blocks that thread_ and makes it unavailable until the logic is done running - which could take a long time
This is true.
> if your users in Bangladesh are using cheap $20 Android phones over 3G connections you still have the same problem and you won't be anywhere near 32ms.
This is of course the crux of the issue. In my opinion, either wait until the infrastructure catches up, or don't write an interactive networked service, for that audience.
Anyway, to at least advance the conversation, I searched for some big open source projects that use EventBus. (https://grep.app/search?q=org.greenrobot&filter[path.pattern][0]=.gradle https://grep.app/search?q=org.greenrobot&filter[path.pattern...). Signal for Android is a good example (https://grep.app/search?q=org.greenrobot&filter[repo][0]=signalapp/Signal-Android https://grep.app/search?q=org.greenrobot&filter[repo][0]=sig...).
Let's just take a look at the first class that appears in search results. "SqlCipherMigrationConstraintObserver." Okay, how in practice does this random thing get registered on the EventBus?
Oh look, it's a file that is just instantiating a bajillion classes: (https://github.com/signalapp/Signal-Android/blob/master/app/src/main/java/org/thoughtcrime/securesms/jobs/JobManagerFactories.java https://github.com/signalapp/Signal-Android/blob/master/app/...) Because dependency injection is stupid on GUI applications, and it messes with all sorts of benefits of direct invocation, they do direct invocation anyway. Except, instead of just like, calling whatever it is they need in SqlChiperMigrationConstraintObserver (or I don't know, just using a Subscription, it's literally called an Observer), they do the same exact work just in a more puzzling way, via instantiating in one class and invoking in... who knows where.
Again, this is why I say toxic. You're going to poke around the repos of what's going on when people actually use EventBus, and you'll discover, in the long term, that people will end up doing O(~direct invocation) work anyway, but stringly typed (or in this case, annotatively typed).
RxJava has its significant downsides. It's still indirect, it's very hard to debug call stacks with them! RxJava call stacks are meaningless. This is the right criticism. The wrong criticism is, "Bad developers can't handle it."
- randiRando 5y agoI agree with your take on event busses but I feel like it describes RxJava pretty well too. > RxJava has its significant downsides. It's still indirect, it's very hard to debug call stacks with them! RxJava call stacks are meaningless. This is the right criticism. The wrong criticism is, "Bad developers can't handle it." How about "It's still indirect, it's very hard to debug call stacks with them! RxJava call stacks are meaningless" and because of that bad developers can't handle it ? Context: Have worked with RxJava (1&2) for about 6 years on different products and I agree that Rx is powerful but it's incredibly easy to over-use and abuse to the point of being a net-negative for a codebase. I think it takes a very disciplined developer to work with Rx. I love/hate Rx