JavaScript SDK を使用してライブ メッセージとプレゼンスを送信する
aura.realtimeの日常的なフローと、実行中のスタックに対して観察された各呼び出しの動作。
1. チャンネルとそのステータス
チャンネルは名前付きルームです。同じ名前を開いたクライアントは、お互いのメッセージを受信します。サブスクライブすると、クライアントは自動的に接続します。
SUBSCRIBEDの後にのみ送信します。その前または拒否の後、send() は送信する代わりに not_connected や requires_subscription などのステータスを返します。チャネルのスコープはプロジェクトに限定されます。2 つのプロジェクトは、相互に認識することなく同じ名前を使用できます。
2. ブロードキャストメッセージ
実際の実行では、2 番目にサインインしたクライアントが 2 秒以内にメッセージを受信しました。
受信するメッセージには、payload に追加されたイベント名が含まれます: { "event": "ping", "n": 1, … }。独自の event キーを持つペイロードは拒否されます(channel.send は 'invalid_payload' を返し、httpBroadcast は realtime_payload_event_reserved を返します)。キー名を変更してください(例: kind)。
- デフォルトでは、独自のメッセージを受信しません。
{ config: { broadcast: { self: true } } }でチャネルを開き、それらを受信します。 - メッセージには
id、topic、timestamp、event、およびpayloadが含まれます。
3. 存在感
プレゼンスは、選択した状態で誰がチャンネルに接続しているかを示します。
presenceState() はユーザー ID によってキー設定されます。各エントリにはユーザーの接続がリストされます。
untrack() を指定するとリストから削除され、チャンネルを離れるかページを閉じると自動的に削除されます。
4. データベースの変更
postgres_changes は独自のデータベースを持つプロジェクトで動作します。まず各テーブルを有効にしてください: PUT /v1/db/{project_id}/schema/tables/{table}/realtime に本文 {"enabled": true} と service_role キーを指定します。リッスンは最初のクライアントが購読したときに始まり、最後のクライアントが離れてから数分後に停止します。配信は少なくとも 1 回です。サーバーの再起動後に同じ変更が 2 回届くことがあるため、ハンドラーは冪等にしてください(例: 行の主キーで判定する)。混雑しているクラスターは容量エラーで新しいリスナーを拒否することがあります。少し待ってから再試行してください。 チャネル名はテーブルに合わせて db:public.<table> にしてください。変更はこのチャネルに配信されます。最初の購読者は、購読の直前に行われた最大 5 秒分の変更を受け取ることがあります。変更は復旧のために 1 時間保持され、その後削除されます。クラスターが満杯の場合、購読は capacité d'écoute postgres_changes atteinte pour la base de ce projet, réessayez で失敗します。受信が 1 分以上失われたままの場合、チャネルは CHANNEL_ERROR になります。復旧したら再度購読してください。1 時間の保持期間より長い障害では、その間の変更は失われます。
5. クリーンアップ
aura.realtime.onStateChange(callback) および onError(callback)との接続を確認します。ドロップ後、 setAutoReconnect(false)を呼び出さない限り、クライアントは自動的に再接続します。