概要

Rx（Reactive Extensions）は、非同期や状態を「ストリーム」として構造化することで、
多くのアプリケーションに予測可能性・テスト性・拡張性をもたらしてきた。

しかしその一方で、Rx設計の中には冗長化・視認性低下・グローバル依存の増加など、限界も見え始めている。
本稿では、Rxの思想を踏襲しながらも、より構造化された「Graph-basedアーキテクチャ」へと進化させる方向性を示す。

1. Rxが切り拓いた価値

イベントや状態を「ストリーム」として抽象化
非同期処理を構造的に合成（map, mergeMap, switchMap）
UIとデータ、APIと状態を一貫した構文で接続
キャンセル・リトライ・エラー処理を制御構造に組み込める

2. しかし、Rxには“構造の限界”がある

❌ ストリームが増えると設計がブラックボックス化

SubjectやObservableが乱立
どこで発火され、どこで使われているかの追跡が困難

❌ データの依存関係が“手続き的”に書かれがち

.pipe() チェーンが長くなると、制御フローが読みにくくなる
オペレータのネスト地獄、複雑なswitchMapの多重合成…

❌ 状態のスコープやライフサイクルが不明瞭になりやすい

Subjectは強力だが、グローバルに広げすぎると意図しない副作用が発生
状態の「所有者」が不明確

3. 次の地平：「Graph-based」なリアクティブ設計

すべてのデータの流れと依存関係を、有向非巡回グラフ（DAG）として定義するアーキテクチャ

例：S.js / Solid.js / Cycle.js などに見られる構造

ストリームが明示的にノード化され、データ依存が双方向でなく一方向
createSignal, createMemo, createEffect 等により、変化の伝播が宣言的

✅ 比較：RxとGraphベースアーキテクチャ

観点	RxJS	Graph-based（Solid/Cycle等）
データ流	Pushベースのストリーム	ノード間の伝播（依存グラフ）
状態の依存管理	明示的ではない（Subject乱立）	宣言的に定義（createMemo等）
デバッグ性	ストリームの流れを追う必要あり	グラフとしてトレース可能
副作用管理	`subscribe`, `tap`, `effect`等	`createEffect` で依存明示
再計算の粒度	ストリーム単位	ノード単位で細粒度更新

4. なぜGraph-basedが“次のリアクティブ”なのか

依存関係の明示的な構造化 → 再レンダリング最適化
変更伝播の局所性 → UIの高効率化
命令的 → 宣言的への遷移 → 保守性・予測性の向上

5. Rxは捨てるべきか？

→ 否。むしろ“構造の構成単位”として昇華すべきである。

状態の変更点 → Rx
外部イベント → Rx
UI更新 → Graph-based

→ Rxの“動的変化制御”と、Graph構造の“静的依存明示”を分離・連携させる設計が理想

6. 現代的リアクティブ設計の姿

// Rxでデータ取得と状態更新を担当
search$
  .pipe(
    debounceTime(300),
    switchMap(query => fetch(query)),
  )
  .subscribe(results => setResults(results)) // Signalなどに更新

// Graph-basedライブラリ（Solid.js等）で宣言的にUIを構築
const [results, setResults] = createSignal([])
createEffect(() => render(results()))

→ 非同期と構造の分離・協調が生まれる

よくある誤解と対策

❌ Rxを使いすぎるとコードが追えなくなる

→ ✅ 正しい。Graph構造による依存設計を導入することで、Rxの責務を“動的イベント制御”に限定できる

❌ Graphベースは学習コストが高い

→ ✅ 最初だけ。依存構造の明示により、実装よりも設計理解が深まる
→ 結果として リファクタ・最適化が容易

❌ Rxは過去の技術？

→ ✅ むしろ **「構造として使える非同期制御ライブラリ」**として再評価すべき時代へ

結語

Rxは、非同期と状態を“流れ”として構造化した思想の到達点である。
だがその次には、依存関係そのものをグラフとして設計に取り込むアーキテクチャが待っている。

Rx = 時間・動作の構造化
Graph-based = 依存・構成の構造化

リアクティブ設計の未来とは、
“非同期の動的制御と、構造の静的構成を分離しつつ統合する、設計のダブルレイヤ化である。”