Supabase RealtimeのBroadcast、Presence、Postgres Changesを使い分ける

三つのイベントモデル

Supabase RealtimeはWebSocketを通じてBroadcast、Presence、Postgres Changesを提供します。Broadcastはクライアント間の一時メッセージ、Presenceは共有状態の追跡と同期、Postgres Changesは認可されたクライアントへデータベース変更を送る機能です。用途を混ぜると、必要な保持性や権限を誤って設計します。

チャットの一時通知ならBroadcast、オンライン状態ならPresence、テーブル更新の購読ならPostgres Changesというように、イベントの意味から選びます。READMEはPhoenix Framework上のElixirサーバーと説明しますが、アプリ固有の認証、再接続、順序制御まで自動で決めるものではありません。

WebSocket接続の最小構成

READMEは最新のDockerイメージをDocker Hubで参照できること、リポジトリがversion 2に注力していることを示します。実際の導入では、利用するイメージ版、環境変数、JWTや認証の設定、公開ポートを公式ガイドと合わせて固定します。READMEにコピー可能な完全な本番composeがない部分は推測しません。

最初は一つのチャンネルと二つの認証済みクライアントを作り、Broadcastの送受信、Presenceのjoin/leave、Postgres Changesの更新通知を個別に試します。接続、切断、再接続のログを取り、イベントが重複した場合にアプリ側で安全に処理できるかを確認します。

認可とPostgres Changes

Postgres Changesは「authorized clients」へ変更を送る機能です。どのテーブル、行、操作を誰が受け取れるかをデータベースのRLS、Realtime設定、クライアント認証の組み合わせで確認します。テーブル変更が見えたことだけでは、不要な行が隠れている証明になりません。

匿名ユーザー、通常ユーザー、管理者の三つのセッションでinsert、update、deleteを試し、受信イベントのpayloadを比較します。JWTの期限切れ、権限変更、チャンネル離脱もテストします。ログにSQLや個人情報が残る場合、収集範囲と保持期間を運用側で定めます。

配信保証を期待しない

READMEのFAQは、サーバーがすべてのメッセージの配信を保証しないと明記しています。Realtimeを状態の補助通知として使うのか、失われると困る業務イベントに使うのかで設計は変わります。後者では、永続データをPostgresに保存し、クライアントが再接続時に差分や現在値を取り直す仕組みが必要です。

Broadcastを注文確定の唯一の記録にせず、Presenceを監査ログの代替にしません。意図的にネットワークを切り、再接続後にDBの現在状態と画面が一致するかを確認します。順序、重複、欠落を測るテスト結果を残し、READMEの非保証を前提に採用範囲を決めます。

開発中のプロジェクトとして追う

READMEはコードベースが活発に開発中で、文書も変化していると述べ、issue作成とrelease監視を案内します。リリース更新ではElixir、Phoenix、Dockerイメージ、認証設定の変更を確認し、接続、三機能、権限、再接続の回帰試験を実行します。

本番の負荷、接続数、レイテンシ、可用性についてREADMEに基準がない場合は、環境固有の測定が必要です。負荷試験ではBroadcastとPostgres Changesを混ぜず、DB負荷、WebSocket切断率、イベント欠落を別々に記録します。

Realtimeの欠落を前提にした採用判断

リアルタイムUI、共有状態、認可されたDB変更通知をWebSocketで扱いたいチームには候補になります。配信保証や履歴管理をRealtimeだけに任せたいシステムには向きません。ライセンスはApache-2.0で、利用条件はLICENSEを確認します。

最初にversion 2のDockerイメージと公式設定で三つのイベントモデルを小さく構成し、二つのクライアント、RLS、切断復帰を検証してください。特に`Postgres Changes`で認可境界を確認し、Broadcastの欠落を許容できるかを業務側と合意できたときにだけ範囲を広げます。

supabase/realtimeを導入候補にする場合は、READMEの最小例をそのまま本番へ持ち込まず、専用の作業場所で入力と出力を保存します。対象バージョン、実行したコマンド、設定ファイル、標準出力、エラー、生成された差分を一組にします。これにより、動いたという印象ではなく、どの条件で再現したかをレビューできます。

確認の途中でREADMEにない機能や保証を見つけたとしても、本文の事実として追加しません。未確認の項目は未確認のまま分け、リリース、issue、LICENSE、公式ドキュメントのどこで確認できるかを記録します。supabase/realtimeの更新で結果が変わったときは、入力を固定して差分を比べ、採用範囲を広げる前に変更理由を確認します。

実務での判定は、機能があるかだけでなく、失敗したときに状態を戻せるかで行います。初回実行前に作業ディレクトリを複製し、設定と生成物の保存先を確認します。正常系ではREADMEの例を再現し、異常系では接続切断、空の入力、権限不足、依存関係の不一致を一つずつ試します。

supabase/realtimeが扱うデータやコードを共有するときは、公開範囲と保存期間を明示します。レビュー担当者が出力だけを見て判断できるよう、入力、版、ログ、差分を残します。数値や利用者の声を引用する場合も、READMEの自称値と自分で測った結果を分けて記載します。

編集部の結論

リアルタイムUI、共有状態、認可されたDB変更通知をWebSocketで扱いたいチームには候補になります。配信保証や履歴管理をRealtimeだけに任せたいシステムには向きません。ライセンスはApache-2.0で、利用条件はLICENSEを確認します。

最初にversion 2のDockerイメージと公式設定で三つのイベントモデルを小さく構成し、二つのクライアント、RLS、切断復帰を検証してください。特に`Postgres Changes`で認可境界を確認し、Broadcastの欠落を許容できるかを業務側と合意できたときにだけ範囲を広げます。 READMEの説明を超える保証は置かず、上記の具体的な入力、設定、ログ、差分を確認できた範囲だけで採用を判断してください。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes