2.フロントエンドだけのサイトに「サーバーサイド」を足す｜Phase 1｜タイピング練習サイトPHP化編（基礎固め）
本記事の位置づけ
本記事は、Phase 1において「フロントエンドだけでは何が足りないのか」を整理する章である。
ここで行うのは、機能を増やすことではなく、責務を分離するためにサーバーサイドを導入する理由の整理である。本記事では、認証や本番運用を前提とした設計は扱わない。それらは後続フェーズで改めて判断する。
HTML/CSS/JavaScriptだけで作られたタイピング練習サイトは、想像以上に多くのことができる。入力判定、スコア計算、表示更新。UXの観点だけで見れば、サーバーサイドがなくても十分に成立する。しかし、その構成には明確な限界がある、それは「正当性の保証が困難」である点だ。
フロントエンドだけの構成では、すべてがユーザーの環境で完結する。開始時刻も、スコア計算も、結果の確定も、すべてがローカルだ。これは即時性という点では優れているが、「それが正しいと言える根拠」が存在しない。そこで、このサイトでは PHP を導入する。目的は機能追加ではなく、責務を分けることにある。
サーバーサイドを導入する本当の目的
サーバーサイドを導入する目的は、単に処理をPHPに移すことではない。
目的は以下の三点である。
- ユーザー操作と結果の正当性を分離する
- 計算結果や事実を、クライアントから切り離す
- 「この結果は正しい」と説明できる境界を作る
フロントエンドは表示と入力を担当し、サーバーサイドは意味付けと確定を担当する。この責務分離が成立して初めて、後続のAPI設計やデータフロー整理が意味を持つ。
JavaScriptはUIと状態管理を担当する。PHPはそれが「正しいかどうか」を判断し、確定させる役割を持つ。この分業が生まれた瞬間、サイトは「動くおもちゃ」から「サービスの原型」に変わる。
重要なのは、いきなりMVCやフレームワークに乗らないことだ。今回は、リクエストを受け取り、処理し、レスポンスを返すという最小構成を、自分の手で書く。ファイル構成も、Controllerとロジックを分ける程度に留める。なぜそう分けるのかを説明できることが先だからだ。
PHPを入れることで何が変わるのか。それは「フロントとバックの境界を言葉で説明できるようになる」ことだ。どこまでがUIの都合で、どこからが業務ロジックなのか。この線引きを体感することが、このフェーズの最大のゴールになる。
次の記事では、この境界を具体的なAPI設計としてどう切り出したのかを扱う。ここまでで「なぜPHPが必要か」が腹落ちしていれば、設計の話に自然と入っていけるはずだ。
サーバーサイドを導入した前提のもとで、
- どの処理を API として切り出すのか
- どのタイミングで通信を行うべきか
- UI と処理の境界をどこに置くのか
Discussion