関数もクラスも書けて、アルゴリズムも組める。それなのに「Webアプリを一つ作って公開する」となると、急に勝手が分からなくなる。フロントエンドとバックエンドは何が違うのか、Reactのコンポーネントとは結局何なのか。プログラミング自体は知っているのに、Webの文脈で出てくる用語で足が止まる、という人は意外と多いものです。
私自身、個人開発でアプリを作りながら、最初にこの壁にぶつかった一人でした。ここでは、最近のWebアプリ開発で出てくる用語と概念を、Next.js と Supabase を例に一枚の地図として整理します。具体的な技術は例にすぎず、考え方は他のスタックでも応用が効きます。
Webアプリは3つの部分でできている
まず大枠の地図を描きます。Webアプリは大きく3つに分かれます。
- フロントエンド — ユーザーが実際に見て触る部分（画面、ボタン、フォーム）
- バックエンド — フロントからのリクエストを受けて、データを処理する部分
- データベース — データを保存しておく場所
普通のプログラムと一番違うのは、Webアプリが「ブラウザ側で動くコード」と「サーバー側で動くコード」という2種類のプログラムの連携で成り立っている点です。最初に混乱しやすいのもここなので、この地図を頭に置いておくと迷子になりにくくなります。
ブラウザは「HTML・CSS・JSを実行する機械」
フロントエンドの正体はシンプルです。ブラウザは3種類のファイルを受け取って解釈し、画面に表示します。HTMLが「何を表示するか（構造）」、CSSが「どう見せるか（デザイン）」、JavaScriptが「何が起きたら何をするか（動き）」を担います。
「ではHTML・CSS・JSだけで作ればよいのでは」と思うかもしれません。小規模なら可能です。ただ、ボタンを押したらリストが増える、入力したら表示が変わる、といった「状態が変わるたびに画面を書き換える」処理を素のJSで全部書くと、すぐに管理しきれなくなります。
なぜReactのようなフレームワークを使うのか
Reactは「画面の見た目を、データ（状態）の関数として宣言的に書く」という考え方を提供します。命令的に「ボタンが押されたらこの要素を書き換えて」と書く代わりに、「この値があるとき、画面はこう表示される」と宣言する。値が変われば、該当部分だけをReactが自動で書き換えてくれます。
ここで出てくる「コンポーネント」は、画面の再利用単位だと捉えると分かりやすいです。普通の関数が「入力（引数）→出力（戻り値）」なのに対し、コンポーネントは「入力（props）→出力（画面の見た目）」です。ロジックの再利用に関数を使う感覚で、画面の再利用にコンポーネントを使う、と置き換えると腑に落ちます。
フレームワークが解決してくれること
Reactは画面の部品を作るライブラリですが、それだけだと、URLごとにどの画面を出すか（ルーティング）、検索エンジンに読んでもらうにはどうするか、画像やビルドの設定をどうするか、といった実用上の課題が残ります。
Next.js のようなフレームワークは、これらを「フォルダ構成のルール」として標準化します。Next.js では、フォルダ名がそのままURLのパスになります。ファイルを置くだけでルーティングが完成するので、「URLの設計＝フォルダ構成の設計」になり、迷いが減ります。私もアプリの管理画面を作るとき、この素直さに助けられました。
つまずきやすい「サーバーで動くか、ブラウザで動くか」
最近のフレームワークで一番つまずくのが、同じファイルの中に「サーバーで実行される部分」と「ブラウザで実行される部分」が混在することです。普通のプログラムは「どこで実行されるか」をあまり意識しませんが、Webアプリではこれが効いてきます。
判断基準はシンプルです。「クリックやフォーム入力など、ユーザーの操作に反応する必要があるか」で考えます。必要なければサーバー側で実行し、データ取得をそのまま書けて速くなります。必要があればブラウザ側で実行します。最初は「全部ブラウザ側にしておけば動く」と考えがちですが、それだとサーバー側で実行する利点を失います。「本当に操作が要る部分だけ」を切り出す意識を持つと、設計がすっきりします。
土台はBaaSに任せる
少し前まで、Webアプリを作るにはサーバーを借り、データベースを設定し、ログイン機能やリアルタイム通信を自作する必要がありました。これらを一つずつ自作するのはハードルが高く、本来作りたいロジックに到達する前に力尽きがちです。
BaaS（Backend as a Service）は、この土台部分をまるごとサービスとして提供します。Supabase はその代表例です。
| 欲しいもの | Supabaseが提供するもの |
|---|---|
| データベース | PostgreSQL（本格的なリレーショナルDB） |
| ログイン機能 | Auth（メール/パスワード、各種ソーシャルログイン） |
| リアルタイム更新 | Realtime（DBの変更を即座にブラウザへ通知） |
| ファイル保存 | Storage |
つまり「自分でサーバーサイドのコードを書かなくても、ブラウザから安全にDBを操作できる」状態を用意してくれるのがBaaSの価値です。個人開発で、App Store や Google Play に出すアプリの裏側を素早く立ち上げたいとき、この恩恵は大きいです。
最初の一本を作るときの心構え
最後に、初めての一本で持っておくと楽になる考え方を挙げます。まず「どこで実行されるコードか」を常に意識すること。これが分かれば多くの混乱が解けます。次に、認証やDBの基本機能は自作せず、土台はBaaSに任せて、自分が書くのはアプリ独自のロジックだけに絞ること。
専門用語は多く見えますが、その多くは過去のプログラミングの知識をWebの文脈に翻訳したものです。実際に小さなアプリを一つ最後まで作ってみると、ここに書いた概念がつながって見えてきます。後編では、この土台の上で必ず向き合うことになる、DBのアクセス制御（RLS）、画面の状態管理、リアルタイム更新の実装を、コードを交えて掘り下げます。まずは小さな一本を、最後まで通してみてください。