React Native × GraphQLで TanStack Queryを 選んだ理由

第3木曜LT会 #31 にて発表させていただいたスライドです

Transcript

1. 2026.07.16 | 第3木曜LT会 #31 React Native × GraphQLで TanStack Queryを 選んだ理由 Reasons for choosing: TanStack Query in React Native and GraphQL development Fullstack Creator Tsubasa SEKIGUCHI
2. 2026.07.16 | 第3木曜LT会 #31 フルスタッククリエイター 関口 翼 関口 翼 Tsubasa SEKIGUCHI aka TinyKitten Tsubasa SEKIGUCHI aka TinyKitten / きったん 2
3. 2026.07.16 | 第3木曜LT会 #31 フルスタッククリエイター TinyKitten タイニーキトゥン aka 関口 翼 3
4. 2026.07.16 | 第3木曜LT会 #31 電車のあの画面、持ち歩けます。 TrainLCD 今までありそうでなかった あなたのスマートフォンで使える トレインビジョン 4
5. 2026.07.16 | 第3木曜LT会 #31 推定到着時間(ETA)機能 ストアリリースしました！ 表示されている分数はあくまで推定です。 実際の経路とは多少の誤差があります。 5
6. 2026.07.16 | 第3木曜LT会 #31 背景の説明 Background: TrainLCD & StationAPI 6
7. 2026.07.16 | 第3木曜LT会 #31 TrainLCD 電車の「あの画面」を再現した モバイルアプリ 🚃 StationAPI 駅データを返す
 自作gRPC API + GraphQL BFF 🗺 使い心地は？ アプリをv10にアップデートした あたりから、なんか重い 🐢 今回扱うシステム 駅一覧を取るたび、
 なんか遅い 7
8. 2026.07.16 | 第3木曜LT会 #31 データの親元 駅データ.jpのCSVを 使用しています 📄 駅データの構造 station_cd は路線ごとの駅
 同一駅は station_g_cd でグループ 🔑 バス情報にも対応 ODPT*1のGTFSデータを 使用しています 🚌 *1 ODPTは公共交通オープンデータセンターのことです データ構造について 駅データ.jpの データをベースに 独自にアレンジ 8
9. 2026.07.16 | 第3木曜LT会 #31 Apollo Clientを辞めた理由 The reasons why Apollo Client was not the right fit 9
10. 2026.07.16 | 第3木曜LT会 #31 Apollo Clientは書き込み時 ネスト全要素を再帰走査して
 キャッシュへ書く 🖋️ __typename 自動注入 全オブジェクト分ペイロードが膨らみ
 JSON.parseも重くなる 🏷 broadcastQueries 書き込みのたび、全useQueryを
 cache.diff で再評価 📡 Apollo Clientの内部処理 observerの数 ×
 グラフの大きさで、
 さらに走査が増える 10
11. 2026.07.16 | 第3木曜LT会 #31 大前提として キャッシュ処理は
 JSのシングルスレッドで実行 🔁 シングルスレッドの中で タッチ・ジェスチャー・
 画面遷移・アニメーションが動作 👆 その結果 駅一覧を取るたびスレッドを占有
 タップや遷移が引っかかる 🌀 実際のところ 操作のレスポンスが
 悪かった理由 11
12. 2026.07.16 | 第3木曜LT会 #31 TanStack Queryを採用した理由 Reasons for adopting TanStack Query 12
13. 2026.07.16 | 第3木曜LT会 #31 前までは React Queryという 名前だったOSS ⚛️ 単なる通信ライブラリではない データ取得に付随するキャッシュ、 再取得、通信状態などをまとめて扱う 🗃️ TanStack Query、実は... APIクライアントそのものではなく、 fetchなどで通信し、その結果と ライフサイクルを管理する 🌱 そもそも TanStack Query って何？ 13
14. 2026.07.16 | 第3木曜LT会 #31 Apollo Clientは 正規化したグラフを キャッシュする TanStack Queryは クエリ結果を そのまま保存する 何をキャッシュするかの違い Apollo Clientが 悪いわけではない 設計の違い 14
15. 2026.07.16 | 第3木曜LT会 #31 ライトウェイトな設計 graphql-requestで
 ただのfetchでのPOSTに 🤝 呼び出し側は Apollo API互換フックで
 書き換えを最小化 🎭 キャッシュ方針 staleTime: Infinity で
 cache-first を等価再現 ♻️ TanStack Queryに置き換える設計 通信の挙動はそのまま
 走査コストを排除 15
16. 2026.07.16 | 第3木曜LT会 #31 まとめ Conclusion 16
17. 2026.07.16 | 第3木曜LT会 #31 今までは 正規化の恩恵ゼロのまま、
 走査コストを負っていた 💸 JSの制約 巨大レスポンス × React Native の
 JSスレッドでは致命傷に 📱 計算量的に言うと big-Oは同じでも、
 定数項が体感を支配する 🧮 まとめ キャッシュは賢さより
 プロダクトとの 相性で選ぶ 17
18. 2026.07.16 | 第3木曜LT会 #31 ご清聴ありがとうございました！ Thank you for listening! Freelance Frontend Engineer Tsubasa SEKIGUCHI