個人開発でサーバーを持つのは、コストも管理も大変です。だからサーバーレスを選びました。その設計を整理しておきます。カサいる？のバックエンドは、Supabase（PostgreSQL + Edge Functions）を基盤に構築されています。サーバーレスアーキテクチャにより、運用コストを抑えつつスケール性を確保しています。
Edge Functionsの構成
1. get-weather（天気データプロキシ）
Open-Meteo APIへのリクエストをプロキシし、レスポンスをジオインデックス付きでキャッシュします。キャッシュキーは「type_lat_lng」形式（緯度・経度を小数点2桁で丸め）で、近接した位置のユーザー同士がキャッシュを共有できます。TTLは1時間で、upsert戦略で更新されます。
2. find-location（ジオコーディング）
Nominatim APIをラップし、住所文字列から座標への変換を行います。クライアントから直接Nominatimにアクセスするのではなく、Edge Functionを経由させることでレートリミットを適切に管理します。
3. send-scheduled-notifications（定期通知）
pg_cronから起動され、アクティブユーザーへの傘判定通知をバッチ送信します。
Row Level Security（RLS）
すべてのテーブルに「auth.uid() = user_id」のRLSポリシーが適用されており、ユーザーは自分のデータのみアクセス可能です。データベースレベルでのセキュリティを保証することで、API側の認可ロジックを簡素化しています。
データベース設計
主要テーブルは以下の通りです：
・kasairu_user_settings: ユーザー設定（ルート・通勤時刻・感度）
・user_notification_tokens: FCMトークン（デバイス単位）
・weather_cache: ジオインデックス付き天気キャッシュ
・notification_error_logs: 通知エラーログ
サインアップ時にはauth_triggerが自動的にユーザーレコードを作成し、アプリ側での明示的なユーザー作成処理を不要にしています。
サーバーレス設計やSupabaseを活用した高速な開発に興味がある方は、ぜひカサいる？紹介ページやその他の技術解説（降水確率判定ロジックの仕組みなど）も併せてご覧ください。