サーバー・API
画面の裏側で、頼まれた処理をしてデータを返す係
画面とデータの間に立ち、「誰が何をしてよいか」を決める。アプリのルールはここにある。
最初に触るなら
Supabase ：PostgreSQLを中核に認証・ストレージ・リアルタイムをまとめたBaaS
データベース・認証・API が最初から揃っていて、サーバーを書かずに「裏側」の役割を体感できる。仕組みが分かったら FastAPI で自分で書く。
隣の分野とのつながり
| 分野 | どうつながるか |
|---|---|
| データの保存 | データを保存し、取り出すのはサーバーの仕事。画面から保存場所に直接触らせない |
| 画面・フロントエンド | 画面に対して API（決まった形の窓口）を用意し、頼まれたデータを返す |
| 認証・セキュリティ | 「本人か」「この操作をしてよいか」の判断はここで行う |
| 実行基盤・ホスティング | サーバーは動かし続ける場所が要る。自前で持つか、BaaS に任せるかを選ぶ |
| 言語・実行環境 （から見ると） | サーバー側の処理は Python・Go・TypeScript などで書く。言語を決めると、使えるフレームワークが決まる |
| 画面・フロントエンド （から見ると） | 画面は自分ではデータを持たない。API を呼んでデータを受け取り、表示する |
| データの保存 （から見ると） | 読み書きの主体はサーバー。画面から直接は触らない |
| 実行基盤・ホスティング （から見ると） | 常時動くサーバーか、呼ばれたときだけ動く関数かで、置き方と料金が変わる |
| 監視・可観測性 （から見ると） | 不具合の多くはサーバー側で起きる。例外を集めて原因をたどる |
| 認証・セキュリティ （から見ると） | 「本人か」「この操作をしてよいか」の判断はサーバー側で行う |
| AI・機械学習 （から見ると） | API の呼び出しはサーバー側から行う。鍵を画面に出さない |
この分野を理解する
API とは何か。 画面がサーバーに頼み事をするときの「窓口」を API と呼ぶ。「このユーザーの注文一覧をください」と決まった形で頼むと、決まった形で返ってくる。窓口の形（URL と入出力）を決めて実装するのがバックエンドの中心作業である。
自分で書くか、借りるか。 FastAPI や Hono のようなフレームワークを使えば、窓口を自分で書ける。自由度は高いが、動かす場所・データベース・認証も自分で用意することになる。Supabase や Firebase のような BaaS（Backend as a Service）は、それらをまとめて貸してくれる。最初は借りて全体の流れを掴み、借り物の制約に当たったら自分で書く、という順序が無理がない。
サーバーが「決める」ということ。 画面のコードは利用者の手元にあるので、書き換えられる前提で考える。「この人は管理者か」「在庫はあるか」のような判断をサーバー側で行うのはそのためである。画面は表示に徹し、判断と保存はサーバーが担う。
隣の分野との境界。 データの置き場所そのものは「データの保存」、動かす場所は「実行基盤」、本人確認の仕組みは「認証」の分野に分かれる。サーバーはそれらを呼び出してつなぐ役である。
最初の一歩。 BaaS で表を1つ作り、画面からデータを1件書き込んで読み戻す。次に同じことを FastAPI で自分で書いてみると、BaaS が何を肩代わりしていたかが見える。
この分野のツール（4件）
種別（自分で書く土台か、借りて使うサービスか）で分けている。「主要制約」は各ツールで最も先に当たる限界。
フレームワーク（2件）自分で書くコードの土台になるライブラリ。動かす場所は自分で用意する
| ツール | 学習 | 料金 | 成熟 | 主要制約 | 検証 |
|---|---|---|---|---|---|
| FastAPI 型ヒントからAPI仕様と検証を自動生成する、Pythonの非同期Webフレームワーク | 低 | 無料 | 安定 | 対応 Python バージョン：Python 3.10 以上（3.10〜3.14 を公式サポート） | |
| Hono Web標準APIのみで書かれ、エッジからNode.jsまで同一コードで動く軽量フレームワーク | 低 | 無料 | 成長中 | 対応ランタイムと Node.js の要件：Node.js は 18.x なら 18.14.1 以上、19.x なら 19.7.0 以上、20.x 以上で、@hono/node-server アダプタ経由で動く。Bun・Deno は Fetch ハンドラをネイティブに実行 |
マネージドサービス（2件）事業者が運用していて、借りて使うサービス。運用を任せられる代わりに、プランの上限が乗る
どれを選ぶか
| ツール | 種別 | どういう時に選ぶか／避けるか |
|---|---|---|
| FastAPI | フレームワーク | Python でデータ処理や AI 推論を HTTP API として公開する用途では第一候補。CPU 負荷の高い処理を1プロセスで並列に捌く必要がある場合、エッジ配置や単一バイナリ配布が要る場合は避け、Go か Hono へ |
| Hono | フレームワーク | TypeScript で HTTP API を書き、Cloudflare Workers・Deno・Bun・Node.js のどこに置くか後から決めたい場合の第一候補。Express 系ミドルウェアの資産を引き継ぐ必要がある場合や、ORM・認証込みのフルスタックが欲しい場合は避け、Next.js か既存の Node.js フレームワークへ |
| Firebase | マネージドサービス | モバイル/Webアプリでリアルタイム同期とGoogle認証を素早く組み込みたい用途では第一候補。関係データの結合や複雑な集計、SQLでの運用が必要ならSupabaseかPostgreSQLへ。Cloud Functionsを使う時点でクレジットカード登録（Blazeプラン）が前提になることは早い段階で確認しておく |
| Supabase | マネージドサービス | 認証・DB・ストレージ・リアルタイムをPostgreSQLベースで一式揃えたい小〜中規模のアプリでは第一候補。無料プランの一時停止や500MBの上限に触れた時点でProへの移行を検討する。MySQL前提の既存資産がある場合や、Google認証・Firestoreのドキュメント構造を前提にしたい場合はFirebaseへ |
この分野が担う目的
目的ごとのページでは、他の分野のツールも含めて横断比較できる。
- HTTP API を公開する （この分野から 2件）
- 利用者を認証しアクセス権を制御する （この分野から 2件）
- 複数クライアント間でデータを即時同期する （この分野から 2件）
- ファイルやバイナリを保存し配信する （この分野から 2件）
- 短時間の処理をオンデマンドで実行する （この分野から 2件）
- 常時起動のプロセスを保持する （この分野から 1件）
- 構造の変わりやすいデータを保存する （この分野から 1件）
- 関係を持つデータを保存し問い合わせる （この分野から 1件）
- ベクトルで類似検索する （この分野から 1件）