2つのフロントエンドと状態管理

本資料は2025/8/28に開催された「MIXI MEETUP！ ーTECH & DESIGN DAYー」における、開発本部 川瀬の資料です。

MIXI MEETUP！ー TECH & DESIGN DAYー
https://mixi.connpass.com/event/363501/

Transcript

1. 2つのフロントエンドと状態管理 川瀬 寛也 開発本部たんぽぽ室たんぽぽグループ
2. 自己紹介 Hiroya Kawase / @h3y6e 開発本部たんぽぽ室たんぽぽグループ mixi2での開発経験 • 以前: Mobile版の開発を担当 • 現在: Web版の開発をリード
3. アジェンダ 1. プラットフォーム特性の理解 WebとMobileの本質的な違い 2. Web: サーバー同期を前提とした設計 TanStack Queryによる状態管理 3. Mobile: 長期稼働とオフラインへの対応 独自のアーキテクチャによる状態管理 4. 実装の詳細と得られた知見 実際の実装例と技術選定の教訓 5. まとめ ユーザー体験最優先のアーキテクチャ選択
4. SNSプラットフォーム「mixi2」 2024/12/16: Mobile版 (iOS, Android) をリリース • Flutter 3 • Riverpod v2 • 追加の状態管理の仕組み 2025/05/16: Web版を後続リリース • Next.js 15 • TanStack Query v5 SNS『mixi』誕生から20年、MIXIの新しいSNS「mixi2」サービス開始！ | ニュース| 株式会社MIXI https://mixi.co.jp/news/2024/1223/37672/ 広がる「mixi2」、PCへ！ブラウザ版サービス提供開始 | ニュース| 株式会社MIXI https://mixi.co.jp/news/2025/0516/41189/
5. ざっくりシステムアーキテクチャ 全体構成 • WebとMobileの2つのフロントエンド • APIサーバーはGoで実装 • Protocol BuffersでRPCの型定義を共有 ◦ Web: Connect, Mobile: gRPC 詳細は Software Design 2025年9月号 新連載「技術選定の舞台裏」【1】mixi2 にて Software Design 2025年9月号 | 技術評論社 https://gihyo.jp/magazine/SD/archive/2025/202509
6. プラットフォーム特性
7. 根本的な違い: ライフサイクルとメモリ管理 Webアプリケーション • 各タブが分離されたメモリ空間 • ページ遷移するとコンポーネント再マウント • リロードですべての状態を再構築 Mobileアプリケーション • 起動から終了まで同一プロセス • メモリ上のオブジェクトを保持しながら画面遷移 • バックグラウンド実行: OSが許す限り状態を維持
8. ライフサイクルが生む問題 • 同一インスタンスを共有 • メモリ管理が重要 • 状態の一貫性が必要 • コンポーネントは画面遷移で破棄 • 意図的な状態管理が必要 Mobile: アプリ単位の ライフサイクル Web: コンポーネント単位の ライフサイクル
9. Web サーバー同期を前提とした設計
10. Web: TanStack Queryの選択 サーバー状態同期に特化したライブラリ • サーバーが常にSingle Source of Truth • キャッシュはパフォーマンス最適化 • @connectrpc/connect-queryでRPCとシームレスに統合 • バックグラウンド再検証で常に最新化
11. 楽観的更新 • UIの即座な反映でUX向上 • サーバー応答を待たない • エラー時は自動ロールバック
12. Web: 複数フィードの一括更新 統合更新の利点 • 複数のフィードで一貫性を保つ • 引用投稿も含めて更新 • 単一の更新関数で管理
13. Mobile 長期稼働とオフラインへの対応
14. Mobile: Riverpodの役割 状態管理ライブラリ 役割 • グローバル状態管理 • ProviderパターンによるDI • テスト時のモック差し替え
15. Riverpodだけでは不十分だった理由 大量コンテンツ管理の課題 • グローバル状態管理: アプリ全体の状態（認証、設定、ナビゲー ション） • コンテンツデータ管理: 大量の投稿やコメントデータ • イベント通知システム: 画面間の更新通知
16. EventHub 課題: 画面間での状態同期 • タイムラインと詳細画面で同じ投稿を表示 • 片方でいいねを押したら、もう片方も更新したい 解決策: イベントバスパターン • 投稿作成、リアクション、リフレッシュ要求
17. ObjectWatchService 同じ投稿が複数画面に表示される問題 • 各画面で別々に状態管理 → 更新の同期が複雑 • メモリ上に同じデータが重複 解決策: オブジェクト単位の監視システム • 個々の投稿を独立して監視 • 変更があった投稿だけを更新 • 全画面で同じインスタンスを参照
18. 役割分担による連携 それぞれの役割 • グローバル状態（Riverpod） ◦ 認証、設定、ナビゲーション • コンテンツデータ（ObjectWatchService） ◦ 投稿、コメントの管理と監視 • イベント通知（EventHub） ◦ 画面間の更新通知 ポイント • 各層が独立して責務を持つ • 必要に応じて連携 • テストが書きやすい設計
19. 実際の動作例：いいねボタン 1. ユーザーがいいねボタンをタップ 2. ObjectWatchServiceで該当投稿を更新 3. EventHubで「いいね追加」イベントを発行 4. 他画面がイベントを受信して表示を更新
20. WatchedObject: Observerパターンの実装
21. Observerパターンの動作 動作フロー 1. ウォッチャー登録: Widgetがオブジェクトを監視開始 2. 更新通知: オブジェクト変更時に全ウォッチャーへ通知 3. 即座提供: 新規ウォッチャーにキャッシュがあれば即提供 効果 • O(1)更新: 変更されたオブジェクトのみ再描画 • データ整合性: 全画面で同一データを参照
22. ObjectWatchServiceによる解決
23. スクロール時の動作 画面単位のキャッシュ管理 • スクロールしても最新データを維持 • 画面単位でメモリ管理 • Riverpodの古いデータ問題を解決
24. Widget統合 これにより解決 • スクロールしても最新データを表示 • Riverpodの古いデータ問題を回避 • 画面単位で効率的に管理
25. ObjectWatchServiceの設計思想 Riverpodとの統合における課題 アーキテクチャ要件と設計判断 • 監視の自動解放 ◦ 課題: 手動管理は危険 ◦ 解決策: Widgetライフサイクルと統合 • 画面単位の管理 ◦ 課題: 複数Widget連携 ◦ 解決策: ScreenCache機構 • データ一貫性 ◦ 課題: 古いデータ問題 ◦ 解決策: 最新データ自動取得 解決策: Widget生存期間とキャッシュ分離
26. Web: TanStack Queryで完結する理由
27. プラットフォーム特性との合致 Webの特性 • 短命ライフサイクル: ページ遷移で破棄 • サーバー中心: 常にAPIから最新データ • 自動メモリ管理: JavaScriptエンジンのGC TanStack Queryが最適な理由 • クエリキーで自動更新: 同じキーの全コンポーネントが更新 • ページ遷移でクリーンアップ: メモリリークの心配なし • サーバー同期特化: キャッシュは一時的
28. 両者の比較: 異なる問題を解決 • 主目的: クライアント内共有 • データ源: メモリ内オブジェク ト • 更新契機: オブジェクト変更 • メモリ管理: 参照カウント • オフライン: 完全対応 • 主目的: サーバー状態同期 • データ源: サーバーAPI • 更新契機: APIレスポンス • メモリ管理: ページ単位 • オフライン: 非対応 ObjectWatchService TanStack Query
29. データフローの比較 • オフラインファースト • ローカルがSSOT • バックグラウンド同期 • 常にサーバーと同期 • キャッシュは一時的 • 楽観的更新でUX向上 Mobile: クライアント中心 Web: サーバー中心
30. Web: 揮発性を前提とした設計 リロードですべて消えるが問題ない理由 1. URLが状態を表現 a. /posts/123 で復元可能 2. 高速取得 a. サーバーキャッシュ、CDN、SSR 3. SEO対応 a. 初期データをHTMLに埋め込み
31. Mobile: オフライン対応のデータ保存 用途別の3層構造 1. 高速アクセス用 a. ObjectWatchService + Riverpod（メモリ） 2. オフライン用 a. Isar Database（ローカルDB） 3. 認証情報用 a. flutter_secure_storage（暗号化）
32. 実装の詳細と得られた知見
33. 実例: 「いいね」機能の実装比較 同じUX、異なる実装戦略 ユーザー体験 • ボタンタップ → 即座にUI更新 → サーバー同期 実装アプローチ • Web: 楽観的更新 + ロールバック • Mobile: ローカル優先 + バックグラウンド同期
34. Web実装 楽観的更新 • 即座性: サーバー応答前にUI更新 • 一貫性: 全フィードを一括更新 • 安全性: エラー時の自動復元
35. Mobile実装 役割分担 • ObjectWatchService: いいね数更新 • EventHub: リスト追加通知 • Isar: オフラインでデータ保持
36. 技術選定の判断基準 既存ライブラリが最適解のケース（Web） • プラットフォーム特性とライブラリの思想が完全に合致 • TanStack Queryの「サーバー中心」設計がWebの本質と一致 • 要件を完璧にカバーし、開発効率も最大化 独自実装が必要なケース（Mobile） • 既存ツールでは解決できない複雑な要件 • 大量データ + 画面間同期 + オフライン対応 • プラットフォーム特有の制約（Dartのデストラクタ不在）
37. アーキテクチャ選択の教訓 実践から学んだ3つの原則 1. 無理に統一しない a. Web/Mobile別々の最適解を選ぶ b. プラットフォームの強みを活かす 2. 車輪の再発明を恐れない a. 必要なら作る勇気を持つ b. 既存の解決策に固執しない 3. ユーザー体験優先 a. 技術的な美しさより実用性 b. プラットフォーム特性を最大限活用
38. まとめ
39. Web: ステートレス → サーバー同期型 • ページ遷移で破棄 ◦ → TanStack Query • 常時接続 ◦ → 楽観的更新 • ブラウザGC ◦ → メモリ管理不要
40. Mobile: ステートフル → クライアント共有型 状態維持 • ObjectWatchService オフライン対応 • Isar DB 手動メモリ管理 • 参照カウント
41. 共通の価値観 ユーザー体験優先 • 即座のUI更新 型安全性 • Protocol Buffers プラットフォーム最適化 • それぞれの強みを活かす
42. Web: TanStack Queryが最適だった理由 実際の課題 • ページ遷移のたびにAPIを再呼び出し • 同じデータを複数コンポーネントで重複取得 • 楽観的更新の実装が複雑 TanStack Queryで解決 • クエリキー: 自動キャッシュ共有 • 宣言的: コード量を大幅削減 • mutation: 楽観的更新の標準化 → サーバー同期型アーキテクチャの確立
43. Mobile: Riverpod + ObjectWatchService 役割を分けた理由 • Riverpod: グローバル状態（認証等）に最適 • 大量コンテンツ: 専用の仕組みが必要 • 画面間同期: 複雑な要件への対応 ObjectWatchServiceで実現 • 細粒度更新: オブジェクト単位 • 自動同期: 画面横断的 • データ維持: スクロール時も最新 → クライアント共有型アーキテクチャの確立
44. 学び 問題を正確に理解し、それを解決する技術を選ぶ 実践した原則 1. 問題の本質を見極める a. プラットフォーム特性の理解 b. ユーザー体験の要件定義 2. 既存ツールを評価する a. 要件との適合性を検証 b. 制約と限界を認識 3. 必要なら作る a. プラットフォーム特性に合わせた設計 b. 既存の解決策で不十分なら自ら作る