HTMLからnpmまで、ここまでの記事はすべて「画面をどう作るか」の話でした。この記事では視点を変えて、その画面の裏側を扱います。
レストランに例えると
フロントエンドは、お客さんの目に触れるホールの仕事です。メニューを見せる、注文を受ける、料理を運ぶ——ReactやVueで組み立てる画面や、JavaScriptの「動き」は、ぜんぶここに当たります。ブラウザの中で、お客さん（利用者）から直接見えるところで動きます。
バックエンドは、厨房の仕事です。注文を受けて、実際に料理を作り、在庫を管理する。お客さんからは見えませんが、これがないと注文は通りません。Webアプリで言えば、データを保存する・誰がログインしているかを確認する・複雑な計算をする、といった処理がここに当たります。
なぜ分けて考える必要があるのか
理由は単純です。ブラウザに送られたコードは、誰でも中身を見られます。 ブラウザの「開発者ツール」を開けば、フロントエンドのコードはほぼそのまま読めてしまいます。
だから、「このパスワードは正しいか」「この人は、他人のデータを見てよい権限があるか」といった、他人に見られては困る判断は、フロントエンド側に書いてはいけません。こうした判断は、利用者の手が届かないサーバー側——バックエンド——で行う必要があります。認証・認可の不備とIDORで扱った事故は、この境界を誤ったときに起きるものでした。
実例：同じアプリの中にある、2つの世界
フロントエンドフレームワークの一長一短で取り上げたJyotish-ONE（インド占星術の計算・鑑定プラットフォーム）は、画面（フロントエンド）はVueで、裏側の計算処理やデータの管理（バックエンド）はPHPという別の言語で書かれています。1つのアプリの中に、はっきり役割の違う2つの世界があるわけです。
なお、フロントエンドとバックエンドを別の言語で書く必要はありません。Node.jsとは何かで見たとおり、JavaScriptはブラウザの外でも動くので、バックエンドもJavaScript（またはTypeScript）で書くという選択肢もあります。Next.jsのAPI Routesは、まさにこの「1つの言語で両方書く」ための仕組みでした。
Vercelの「バックエンドどうする問題」
そもそもVercelとは何かで見たとおり、Vercelは「組み立て（ビルド）・配達・住所・鍵マーク（https）」をまとめて引き受けてくれるサービスです。ここに、サーバーレス関数（リクエストのたびに立ち上がって、処理が終わったら消える、短命なバックエンド処理）を書く仕組みもあります。
ただし、Vercelが持っているのは「処理」の場所であって、「保管」の場所ではありません。 サーバーレス関数はリクエストが終わると消えてしまうので、そこにデータを覚えさせておくことはできません。会員登録の情報、投稿の内容、注文の履歴——何かを長期間覚えておきたくなった時点で、Vercelとは別に、データを預かってくれるサービスが必要になります。 これが「バックエンドどうする問題」の正体です。
そもそもデータベースって何か、いつ要るのかにあるとおり、まず本当にそれが要るのかを先に考えるのが遠回りをしない近道ですが、要るとなったら、次は「どこに預けるか」を選ぶ番です。
選択肢の見取り図
いま名前をよく見るのは、次のようなサービスです。それぞれの詳しい比較は別記事に譲り、ここでは位置づけだけ整理します。
| サービス | 位置づけ |
|---|---|
| Turso | SQLite（JavaScriptとは何かのような軽量さを、データベースの世界でやろうとしている）をベースにした、身軽なデータベース |
| Supabase | PostgreSQL（本格的なリレーショナルデータベース）をベースに、データベース・ログイン機能・ファイル保存までまとめて提供する「オールインワン」型 |
| Firebase | Googleが提供する、同じくオールインワン型のサービス。データベース・ログイン機能・ホスティングまで含む、老舗の選択肢 |
| Node.jsで自作 | サービスに頼らず、Node.jsで自分のバックエンドを書き、別のデータベースと組み合わせる方法。自由度は高いが、組み立てる範囲もいちばん広い |
大きく分けると、「データベース＋周辺機能をまとめて肩代わりしてくれるサービス」（Supabase・Firebase）と、「土台だけを提供するので自分で組み立てる」（Turso、あるいはNode.js自作）という2つの方向があります。どちらが向くかは、フロントエンドフレームワークの一長一短と同じく、作りたいものの規模と、どこまで自分で決めたいかによります。それぞれの詳しい比較は、データベース系の記事で改めて扱います。
かつてより、遥かに充実している
昔は、バックエンドを持つというと、自分でサーバーを借りて、OSの設定から始める必要がありました。JavaScriptとは何かで触れたとおり、当時はPerlやPHPのようなサーバー側の言語を使い、動かす場所も自分で管理するのが当たり前でした。
いまは、TursoやSupabase、Firebaseのようなマネージドサービス（面倒な管理をサービス側が肩代わりしてくれる仕組み）のおかげで、サーバーの管理そのものをほとんど意識せずにバックエンドを持てるようになっています。フロントエンドの選択肢が増えたのと同じように、バックエンドの選択肢もこの数年で大きく広がりました。
まとめ
- フロントエンドはブラウザ側で動く、利用者から見える部分。バックエンドはサーバー側で動く、見えない裏方の部分
- ブラウザのコードは誰でも読めるので、他人に見られて困る判断はバックエンド側で行う必要がある
- Vercelが持っているのは主に「処理」の場所で、「保管」の場所ではない——データを長く覚えておきたくなったら、別途データベースサービスが要る
- Turso・Supabase・Firebase・Node.js自作など、選択肢は年々充実している