RX Javaサーバー側のエンジニアが必要とするものですか？
RXがAndroidおよびUIイベント処理に適していることがわかります。RXがバックエンドでどのようなメリットを提供するかを確認するのに苦労しています。
RX Javaはバックエンド処理用に設計されたのですか、それともこの概念は行き過ぎでしたか？
実際、RxJavaは、サーバー側の問題に取り組むために最初に実装されました。リアクティブ拡張機能は.NETの世界から始まり、Netflixによってバックエンド用にJavaに移植されました。 RxJavaは、Androidに採用される何年も前に、サーバー側のJavaプログラミングで使用されるようになりました。
当時、非同期および非ブロッキング処理は、サーバーのパフォーマンスを大幅に向上させることが証明されていました。これを達成するためにコールバックを使用することもできますが、コールバックはうまく構成されず、コールバック地獄につながります。機能的なコールチェーンスタイルを備えたRxJavaは、（優れた）ソリューションを提供し、採用され始めました。
次に、それはAndroidに広がり、ネットワーク呼び出しまたはUIイベントを処理します。私はAndroidでそれを使用して楽しんでいますが、RxJavaはサーバーよりもAndroidの方が家にいることが少ないことが常にわかりました。一般的な設計は他のサーバーテクノロジIMHOに概念的に近いため、.NETの世界では、最初からクライアント側でリアクティブ拡張が使用されていたことがわかっていても。しかし、AndroidでのRxJavaの使用には欠陥があるためです。サブスクリプションを追跡しないと、Contextが簡単にリークする可能性があります。そして、.observeOn(AndroidSchedulers.mainThread())をほぼすべての場所に追加する必要があります。これは、時々忘れてクラッシュにつながることを忘れてしまいます。 Androidチームを率いて、 Livedata on Architecture components でObserverパターンを独自に取り入れたのはそのためだと思います。
コールバック地獄を解決することに加えて、RxJavaは開発者に提供します：
- オブザーバーパターン：このパターンは、データを他のモジュールに公開するのに最適です。これは、定義された標準的な動作、終了の処理、およびプロデューサーをコンシューマーに制御する方法（サブスクリプション解除、バックプレッシャ）を使用して、プロデューサーとコンシューマーの間で契約を結びます。もちろん、このパターンを実装するためにRxJavaは必要ありませんが、RxJavaはそれを別のレベルに引き上げます。
- エラー処理：非同期システムでは、エラー処理には注意が必要です。
- 演算子の完全なセット：ストリームを変換、フィルタリング、結合するための100を超える演算子。実行するデータ操作があり、通常はバックエンドがそれを中心に展開している場合、RxJavaはコードをいくつかの標準の明示的な演算子に要約します。
Android IMHOよりも、RxJavaはバックエンド処理に最適です。 Netflixがリアクティブ拡張機能をJavaに実装した理由と、バックエンドのメリットがどこにあるのかについて詳しく知ることができます here 。
サーバーサイドエンジニアに必要かどうかというと、必須ではないと思いますが、それを知っているとツールボックスが大幅に強化されます。今日、トレンドはますます非同期になり、非同期APIのみを提供するミドルウェア、ライブラリ、フレームワークがますます増えています。 Couchbase JavaデータベースAPIは、たとえばRxJavaに基づいています。さらに、リアクティブエクステンションはJavaだけでなく、ほとんどの言語でこの知識を活用できます。
私は、APIゲートウェイと従来のマイクロサービスの両方でRxJavaを使用しています。 Rxが取るに足らないことは、並列計算（またはI/O呼び出し）にローカルとグローバルの両方の制約があることです。私は、同様に機能する非反応性のソリューションを見つけていません。
とは言うものの、マイクロサービスが孤立して存在することはなく、すべてが他の何かに連絡する必要があります。
私の経験では、テストは特に複雑ではありません。追加のツールが必要ですが、それは1回限りの投資です。
ほとんどのrxチュートリアルは、subscribeの方法を示すことに焦点を当てていることに気づきました。それは間違った抽象化レベルだと思います。 IMOオペレーターレベルの思考とテストははるかに便利です。