4.セッション開始から終了までのデータフローを分解する｜Phase 1｜タイピング練習サイトPHP化編（基礎固め）
本記事の位置づけ
本記事は、Phase 1におけるデータフロー整理の総まとめである。
これまでに整理してきたフロントエンド、サーバーサイド、DBの責務分担を、セッション開始から終了までの流れとして確定させる。ここで扱うデータフローは、設計思考を整理するためのものであり、実運用を前提とした最終形ではない。
結論から述べる
このタイピング練習サイトでは、セッションの開始と終了だけをサーバーサイドの責務とし、それ以外の処理はフロントエンドに任せている。この分担によって、処理の流れとデータの意味を明確にできると判断した。
まず、ユーザーが「スタート」ボタンを押した瞬間を考える。JavaScript側では、UIの状態を初期化し、タイピング画面へ遷移する。同時に、選択中のカテゴリ情報を取得し、セッション開始APIを呼び出す。この時点でフロントエンドが送信するのは、「どのカテゴリで始めたいか」という事実のみである。
PHP側では、受け取ったカテゴリが正当なものかを検証する。その後、新しいセッションIDを発行し、開始時刻をサーバー時刻で確定させる。この情報を sessions テーブルに保存した時点で、「セッションが開始された」という事実が初めて成立する。ここが、フロントエンドだけの世界と、サーバーサイドが関与する世界の明確な境界線となる。
タイピング中の処理
このフェーズでは、API通信は一切行わない。入力判定、文字カウント、ミス判定、残り時間の管理といった即時性が求められる処理は、すべてJavaScript側で完結させる。サーバーに送らない、という選択自体が設計である。
ここで重要なのは、JavaScript側が「状態を保持している」だけで、「結果を確定していない」という点だ。途中経過はあくまで一時的なものであり、サーバー側の真実にはならない。
タイピングが終了すると、JavaScriptはセッション終了APIを呼び出す。送信するのは、sessionID、入力文字数、ミス数、経過時間といった事実データである。WPMや正答率などの計算結果は含めない。意味付けを伴う処理は、必ずサーバー側で行う。
PHP側では、まず sessionIDの存在確認と未終了チェックを行う。問題がなければ、受け取った事実データを基にスコアを計算し、scoresテーブルに保存する。同時に、sessionsテーブルの終了時刻を更新することで、セッションは正式にクローズされる。
このデータフローで意図的に省略していること
本フェーズのデータフローでは、以下の要素を意図的に含めていない。
- 認証・認可を含むアクセス制御
- 異常系を網羅した運用フロー
- セキュリティ事故を想定した対処設計
これらは重要であるが、設計の初期段階で同時に扱うと、責務境界の理解が曖昧になる。まずは、「どの処理が、どの層の責務か」を明確にすることを優先する。
役割
この一連の流れを通して一貫しているのは、役割分担である。
- JavaScriptは「集めるだけ」
- PHPは「意味を与えるだけ」
- DBは「記録するだけ」。
この線を越えないようにすることで、処理の見通しが良くなり、後からの修正や拡張も容易になる。
データフローを図に起こすと、処理自体は決して複雑ではないことが分かる。しかし、この流れを言葉で説明できるかどうかは別問題だ。本章で行っているのは、実装そのものではなく、「なぜこの順番で、なぜこの責務なのか」を言語化する作業である。
次は
次の記事では、ここまで整理したデータフローを前提に、APIエンドポイントの具体的な構成と、別案と比較した際の判断理由を整理する。ここまでで、Phase 1における設計整理は一通り完了した。
次の Phase 1.5 では、ここで整理した設計を前提として、
- 認証を自前で実装すべきか
- セキュリティ責務をどこまで負うべきか
- 実運用を考えたときに、どこを委譲すべきか
といった点を改めて検討し、設計判断を更新する。
Discussion