付録B　クライアントから直接DB？ — Supabase/Firestore の“バックエンドレス”と RLS／セキュリティルール

📖 このページのゴール：Supabase や Firestore の 「ブラウザから直接DBを触る」 という作り方が、ふつうと何が違い・なぜ成立し・いつ向くかがわかる。あわせて RLS と Firestore セキュリティルール の関係も整理する。 ← 目次・はじめにへもどる

🤔 ふつうの作り方：あいだに「自分のサーバー」を挟む

多くのアプリは、こう作ります（姉妹教材 ChatGPTクローンで「自分のサーバーを挟む」と言ったのと同じ）。

ブラウザ  →  自分のバックエンドAPI  →  データベース
                （ここで「誰が何をできるか」を判断）

ポイントは、DBを外（インターネット）に直接さらさないこと。「このユーザーは自分の投稿しか消せない」といった認可（できること／できないことの判断）は、バックエンドのコードが担当します。これがいちばん一般的な作りです。

🌀 Supabase / Firestore の“変則”：ブラウザが DB をほぼ直接さわる

ところが Supabase や Firestore は、ブラウザ（クライアント）から、DBのAPIをほぼ直接たたきます。

ブラウザ  →（SDK：supabase-js / firebase）→  DBのAPI に直接
        （CRUDのためのバックエンドを、ほとんど書かない＝“バックエンドレス” / BaaS）

「投稿を取る・足す・消す」程度のために、自分でAPIサーバーを書かない。SDK で supabase.from('posts').select() や Firestore の getDocs(...) を画面から直接呼びます。
だから爆速で作れる——これが、個人・スタートアップに人気の理由です（姉妹教材 Twitter/ChatGPTクローンも Supabase）。

❓ でも待ってください。DBを外に直接さらして、安全なの？ ——ふつうの感覚だと「危ない！」ですよね。ここがこの作り方のキモです。

🔑 なぜ安全？ — 「認可」をデータの層に押し下げる

秘密は、「誰が何をできるか」の判断を、バックンドのコードではなく、データの層（DB側）に持たせることです。だからDBを直接さらしても、ルールに反する操作はDB自身が弾く。

Supabase ＝ RLS（行レベルセキュリティ） PostgreSQL のテーブルに「この行は、この人だけ」というポリシーを貼ります（例：auth.uid() = user_id）。DB が一行ずつ「あなたに見せていいか／変えていいか」を判定します。

Firestore ＝セキュリティルール 専用のルール言語で、ドキュメント単位に判定します。

match /posts/{id} {
  allow read: if true;                       // 読むのは誰でもOK
  allow write: if request.auth.uid == resource.data.user_id;  // 書けるのは持ち主だけ
}

どちらも考え方は同じ——認可をデータ層に押し下げて、クライアント直アクセスを安全にする。これが「バックエンドレス」を成立させる土台です。

⚠️ なぜ“変則”で、一般的ではないのか

ふつう（とくに企業の大きなシステム）は、認可や業務ロジックをバックエンドのコードに書きます。Supabase/Firestore は、それをDBのポリシーやルールに置く——発想の転換です。良い面と注意点はこうです。

	良い面 👍	注意点 ⚠️
開発速度	CRUDのバックエンドがほぼ要らず爆速	複雑な業務ロジックは結局 Edge Functions / サーバーが要る
安全	DBが一律に守る（書き忘れの穴が出にくい）	ルール/RLSを間違えると即データ漏洩（Firebaseの「ルール全開放」事故は定番）
考え方	少人数・素早い反復に向く	「RLSで考える」慣れが必要。監査が厳しい現場では重い

🔒 鉄則：直アクセスにするなら、RLS／セキュリティルールを最優先で正しく書く。公開鍵（anon キー）は「RLSで守られている」前提で配られています。「他人のデータが見えない／消せない」ことをテストで必ず確認してください。これは姉妹教材 Twitter/ChatGPTクローンの「データは誰のもの？（RLS）」と地続きの話です。

🆚 RLS と Firestore セキュリティルール — 似て非なる兄弟

	RLS（Supabase / PostgreSQL）	Firestore セキュリティルール
土台	リレーショナルDB（SQL）	NoSQL（ドキュメント）
単位	行（レコード）	ドキュメント／パス
書き方	SQLのポリシー（`using` / `with check`）	専用ルール言語（`match` / `allow`）
得意	SQLの条件をフルに使える・既存RDB資産	パス構造に沿った素直な権限・モバイル
共通点	認可をデータ層へ。クライアント直アクセスを安全化	同左

🌩 ついでに：直アクセスだからできる「リアルタイム」

この「クライアントが直接つながる」作りは、リアルタイムとも相性抜群です。Firestore は購読（onSnapshot）で変更が即・全員の画面に反映、Supabase も Postgres の上に Realtime を載せています。普通のRDBを自前で立てた場合、ここは自分で WebSocket などを作る必要があります（→ 本編 08 NoSQL代表サービスの「クラウドならではの強み」も参照）。

🟢 ひとことで言うと

Supabase/Firestore の 「ブラウザから直接DB」 は、ふつうの「バックエンドを挟む」やり方とは逆で、認可をDB側（RLS／セキュリティルール）に持たせることで成立しています。速く作れて強力だけど、ルールを間違えると即漏洩。だから「直アクセスを選ぶ＝RLS/ルールを正しく書く責任を負う」とセットで覚えてください。

← 目次・はじめにへもどる

付録B クライアントから直接DB？ — Supabase/Firestore の“バックエンドレス”と RLS／セキュリティルール