バックエンドはなぜ生まれたのか
1993年のサーバーは保管庫でした。ユーザーがアドレスを入力すると、あらかじめ保存しておいたHTMLファイルを取り出して投げ返す、それで終わりです。ところがゲストブックの登場で壁にぶつかります。訪問者Aが残した書き込みを訪問者Bに見せるには、誰がいつ何を書くかを事前に知っていなければならず、それは不可能です。
そこで発想が変わりました。ファイルを事前に作るのではなく、リクエストが来たその場でページを作ればいい。1993年に登場したCGIがその最初の道具で、サーバーの役割はファイルの保管から製造へと変わりました。これがサーバーサイドレンダリングであり、バックエンドの出生届です。
DB・MVC・APIはどんな問題を解いたのか
ゲストブックの書き込みを保管する場所が必要でした。最初はテキストファイルに一行ずつ積んでいましたが、数千件になると一件を探すのにファイル全体を読まなければなりません。1995年にMySQLのようなリレーショナルデータベースが登場した理由です。
機能が増えてコードが一つのファイルに絡み合うと、データ(M)・画面(V)・交通整理(C)に役割を分けるMVCパターンが生まれました。そして2007年、iPhoneが登場します。アプリに必要なのはHTMLではなくデータで、HTMLの製造者だったサーバーはJSONでデータを供給するAPIサーバーへと再び変わります。バックエンドとフロントエンドという職種が明確に分かれたのも、まさにこの時点です。
セッション・キャッシュ・トランザクションはなぜ生まれたのか
HTTPには記憶力がありません。ログインしても、次のリクエストでサーバーはその人を認識できません。そこで番号札を発行するセッションと、その番号札をブラウザに保管するクッキーが生まれ、サーバーが複数台に増えると、署名で偽造を検証するJWTが登場しました。パスワードはハッシュ化を経て、DBが流出しても原文が分からない形で保存します。
ユーザーが増えてサーバーが遅くなると、よく使われるデータをメモリに載せておくキャッシュ(Redis)が生まれ、口座振替が途中で切れてはならないため、全部成功か全部取り消しかというトランザクションが生まれました。それでも限界が来ればサーバーを強化する代わりに台数を増やす水平スケーリングへ、コードの塊が大きくなりすぎれば機能ごとに分割するマイクロサービスへと進みます。すべて問題解決の産物です。
バックエンド言語は何を選べばいいのか
結論から言えば、どれを選んでも構いません。ログインの本質は「IDが存在し、パスワードが一致すれば通過」、条件文二つです。Pythonはifの後にコロンが付き、Javaは波括弧が付く、その程度の文法差があるだけで構造は完全に同じです。PHP、Python、Java、Goがどれほど違って見えても、やっていることは一つ、HTTPリクエストを受けて処理し、レスポンスを返すことです。一つ身につければ、残りは方言レベルです。
非開発者がこの系譜を知ると何が変わるのか
AIへの指示が変わります。「ログインを作って」が「認証はJWTで、パスワードはハッシュ化して保存して」に変わります。流れをつかめばAIの成果物に欠けている部分が見え、指示が具体的なぶん結果の品質が上がります。SH Consultingのバイブコーディング教育でバックエンドを歴史の順番で解きほぐすのは、これが理由です。すべての技術は何らかの問題を解くために生まれ、その問題を知れば技術は暗記ではなく理解の対象になります。