TanStack Query × Dexie.js で「プロトタイプを全部捨てる」から卒業する境界設計

はじめに こんにちは、Dress Code株式会社でプロダクトエンジニアをしているもず（@mozu1206）です。 データ構造やAPI設計までしっかりやる時間はないけれど、ビジネスサイドと「作成・更新・削除まで動く画面」で会話を進めたい場面、ありませんか？AIで雑にプロトタイプを作る選択肢もありますが、本実装に入るときに全部捨てるのは、正直もったいないですよね。 この記事では、フロントのみでプロトタイプを作りつつ、API繋ぎ込み時に捨てるコードを最小限にする設計（-api → -query → コンポーネントの3層構造）を紹介します。 TL;DR -api 層にデータのやりとりを閉じ込め、バックエンド完成後にそこだけ丸ごと差し替える方針をとりました。データ永続化にはDexie.js（IndexedDB）を使い、TanStack Queryと組み合わせることで、-query 以上のフロントは

[simplememofast]

境界設計で効くのは三点。一・RemoteとLocalの責務を関数名で表す。二・失敗時の戻り口を一本化する。三・キャッシュTTLは利用頻度で決める。他に大事な軸ある？

[nguyen-oi]

APIを差し替えるだけでモックから本実装に移行できる境界設計、開発スピード的にもかなり熱い

[mkusaka]

TanStack Query×Dexie.jsで、-api→-query→コンポーネントの3層に分けDexie(IndexedDB)を差し替え可能にする設計