状態管理の設計 — サーバーとクライアントで何を持つか - システム設計をちゃんと理解する

学習者

状態って全部フロントで持てばよくない？わざわざサーバーと切り分ける意味があるの？

なぜ「どこに持つか」を考える必要があるのか

アプリケーションには様々な「状態」が存在する。ユーザーの入力中のフォームデータ、APIから取得した一覧データ、ログイン中のユーザー情報、UIの開閉状態など。

これらを「とりあえず全部フロントで持つ」「とりあえず全部サーバーに問い合わせる」とすると、どちらの場合も問題が起きる。状態の置き場所を設計段階で決めておくことが、保守性とパフォーマンスの両方に影響する。

状態はその性質によって、適切な管理場所が異なる。

データの正（Single Source of Truth）がサーバー側にあるもの。DBに保存されている情報が該当する。

フロント側ではキャッシュとして一時的に保持するが、正のデータはサーバーにある。React QueryやSWRのようなライブラリはこのサーバー状態の取得・キャッシュ・再取得を管理するためのものである。

フロントエンド側でのみ意味を持つ状態。サーバーに保存する必要がないもの。

これらはReactであれば useState や useReducer、あるいはグローバルな状態管理ライブラリ（Zustand、Jotaiなど）で管理する。

一部の状態はどちらとも言い切れないケースがある。

こうした状態は「どちらが正か」を明確に決めておく必要がある。たとえば下書きなら「最後にサーバーに保存された値が正」とし、クライアント側は未保存の変更を持つ一時的な状態として扱う。

状態管理の設計では「どのデータをどこに持つか」だけでなく、「データの加工・整形をどの層が担うか」も重要になる。

たとえばAPIから取得した生データをそのままフロントの状態に入れることは少ない。日付のフォーマット変換、ネストされたオブジェクトのフラット化、不要なフィールドの除去など、何らかの加工を経てからUIで使える形になる。

この加工処理をフロントに置くと、フロントの状態管理層にAPIの仕様に関する知識が入り込む。APIの仕様変更があるたびにフロントを修正する必要が生じ、UIロジックとデータ整形ロジックが混在してコードの見通しが悪くなる。

BFFはフロントエンド専用の中間サーバー層である。バックエンドのAPIとフロントエンドの間に置き、フロントが必要とする形にデータを整形して返す。

役割は「データの加工・整形」に限らない。複数のAPIへのリクエストを1回にまとめる集約、フロントに不要なフィールドの除去、認証情報のサーバー側への隠蔽なども含む。

BFFを置くことで、フロントの状態管理層は「整形済みのデータを受け取って保持し、表示する」ことに専念できる。APIの仕様変更はBFF層で吸収されるため、フロント側のコードが安定する。

「どの層がどの状態を持ち、どこで加工するか」を設計段階で決めておくことで、各層の責務が明確になる。

これらを事前に決めておくことで、実装時に「この値はどこに持つべきか」で迷うことが減り、コードの一貫性が保たれる。