従来型Webアプリの裏側をスッキリ整理してみた
はじめまして！
35歳未経験でエンジニアを目指し日々奮闘している者です。
Webの勉強を始めてすぐ、こんなことありませんか？
「画面は動くけど、裏で何が起きてるのか説明できない…」
僕もそんな状況でした。
この記事では、そんなモヤモヤを整理するために、
従来型のWebアプリケーションの仕組みをシンプルに解説します。
今回は「牛丼屋」に例えながら、イメージで理解できるようにお伝えします！
この記事はこんな人におすすめ
-
「Webアプリの裏側」と聞くと、なんとなく難しそうで手が止まる方
-
「HTTPはステートレス」と聞いて、理解した気になるけど説明できない方
-
「フレームワークが何をやってくれているのか」が曖昧な方
参考書籍：小森裕介『プロになるためのWeb技術入門』
ズバリ結論！
従来型のWebアプリケーションを、一言で言うとこうです。
「サーバーという名の“ワンオペ店長”が、注文ごとに記憶喪失になるバイトをフォローしながら、毎回フルコースを作り直して提供している状態」
…なかなかハードな現場ですよね（笑）
このイメージがつかめると従来型Webアプリの動きがかなりクリアに見えてきます。
ここから、順番に分解していきます。
Webアプリ開発、ここがツラいよ。
Webアプリを作るのが難しい理由は、根底に「2つの厄介な性質」があるからです。
1. HTTPは「毎回はじめましてのバイト（ステートレス）」
ブラウザとサーバーを繋ぐ「HTTP」というルールは、「ステートレス（状態を持たない）」という性質があります。
例えるなら、1リクエストごとに記憶がリセットされるアルバイトです。
僕：「牛丼ください！」
バイト：「はい、牛丼ですね！」（提供）
僕：「あ、やっぱり卵も追加で！」
バイト：「……申し訳ありません、初めてのお客様でしょうか？」
さっきのやり取り、全部リセットされてます。
悲しいですが、毎回「さっき牛丼を頼んだ者です」と自己紹介しないと、同一人物だと認識してくれません。
これがステートレスの正体です。
2. 同時に100人から注文が来る（複数ユーザーの同時利用）
Webアプリは、同時に何百人もの人が使います。
記憶喪失のバイトに対して、同時に100人が「牛丼！」「カレー！」と叫んでいる状態です。
これを絶対に間違えず処理しないといけません。
従来型Webアプリの「力技」アプローチ
この「記憶喪失」と「大行列」のハードな現場。
従来型のWebアプリは「裏のサーバー（ワンオペ店長）が、毎回『完成品』をゼロから作って出す」という超絶・力技で解決しました。
具体的にはこんな感じです。
調理も盛り付けも、ぜーんぶ店長（サーバーがHTMLを生成）
お客さん（ブラウザ）は、席で待つだけ。裏の計算から「どんぶりの見栄え（HTMLの組み立て）」まで全部サーバーがやります。ブラウザは「運ばれてきた完成済みの牛丼を、ただ食べる（表示する）だけ」の受け身な存在です。
「生卵追加」だけで、牛丼をゼロから作り直す（画面遷移の仕組み）
リンクを押して別の画面に移動する（画面遷移する）のは、「やっぱり生卵追加で！」とお願いするイメージです。
普通なら生卵だけ小鉢で渡せばいいのに、従来型は違います。
「食べてる途中の牛丼を一旦没収し、厨房で『最初から生卵が乗った新品の牛丼』をイチから作り直して出す」という狂気のオペレーションをします。
リンクを押すと画面が一瞬「チカッ」と白くなるのは、この「どんぶり（画面）まるごと強制交換」が起きているからです。
※ブラウザがページを一度リセットして、新しいHTMLを読み込み直しているため
記憶喪失をカバーする「クッキーとセッション」
最大の課題は「記憶喪失のバイトに、どうやって自分を覚えさせるか？」
その答えが、「セッション」と「クッキー（Cookie）」です！
・セッション（店長の裏メモ）
サーバー（店長）の裏に、僕ら専用の「注文メモ」を作ります。
「この人は牛丼注文済み」とコッソリ書いておきます。
・セッションID（引換券の番号）
そのメモと照らし合わせるための「引換券（番号）」を発行します。
・クッキー / Cookie（お客さんの財布）
店長は引換券をブラウザ（お客さん）に渡し
「財布（クッキー）にしまっといて！」とお願いします。
以降、お客さんは注文するたびに「財布（クッキー）から引換券（セッションID）を見せる」ルールになります。
これでバイトも「あ、引換券999番の牛丼の人ですね！」と裏メモを見て思い出せるわけです。
平和！
シンプルな図で流れを整理してみました。
【ブラウザ（お客さん）】 【サーバー（ワンオペ店長）】
| |
| 1. 「ログインさせて！」(ID/Pass) |
|----------------------------------------->|
| | (認証OK!)
| | ・裏メモ作成（セッション）
| | ・引換券番号を発行（ID: 999）
| |
| 2. 「ログイン完了画面」と「引換券 999」を返す |
|<-----------------------------------------|
(財布(Cookie)に999をしまう) |
| |
| 3. 「マイページ見せて！」 |
| (財布の引換券 999 を一緒に見せる) |
|----------------------------------------->|
| | (お！番号999だからあの人だ！)
| | ・999の裏メモを確認
| | ・マイページの画面を作る
| |
| 4. 「マイページの画面」を返す |
|<-----------------------------------------|
だから「フレームワーク」に頼るんです
ここまで整理してみて、僕は思いました。
「引換券作って、毎回番号確認して、画面も手作りして……店長の負担エグすぎない？」
そうなんです。「状態の維持（セッション管理）」と「ユーザーの区別」には、めちゃくちゃ手間がかかります。これを毎回ゼロから手作業でプログラミングするのは、まさに苦行です。
そこで先人たちが作ってくれたのが、「Webアプリケーションフレームワーク」です！
フレームワークが、この面倒な「引換券のやり取り」や「裏方の雑務」というシステム部分などの、よく使う処理をまとめて提供してくれます。おかげで開発者は、「どんな美味しい牛丼（サービス）を作るか」という本質的な部分に集中できるんですね。
まとめ
僕の理解を、最後にまとめます。
・HTTPは記憶喪失なので、放っておくと誰が誰だか分からなくなる。
・だから、「Cookie（引換券）」と「セッション（裏メモ）」を使って
サーバー側で必死にユーザーを記憶している。
・その「超面倒くさい裏方作業」を丸投げできるのがWebフレームワーク。
少しでも、「あ、そういうことだったのか！」とスッキリしていただけたら嬉しいです。
次回はSPAへの進化を記事にしたいと思います！