概要
Sync Gatewayは、レプリケーションプロセスを拡張し、ドキュメントの変更に対応するレスポンシブサービスを構築する機能を提供します。これによって、モバイルアプリケーションと同じサービスをWebアプリケーションとして提供する際の様に、サービス全体のエンドツーエンドのプロセスに付加価値を与えることができます。
Sync Gatewayは、変更フィードとWebhookという二つの方法を提供しています。これらの比較について、次の表を参照してください 。
| 変更フィード | Webhook | |
|---|---|---|
| 方式 | プル | プッシュ |
| シーケンス/順序付け | はい | いいえ |
| ユーザーアクセス制御 | 細粒 | 限定的 |
| スケーラブル | はい | いいえ |
| 失敗時のデータストリームの再生 | はい | いいえ |
ユースケース
- 「needs-email」というチャネルがある場合、電子メールを送信してから、「needs-email」チャネルに入らないようにフラグを付けてドキュメントを保存するボットを作成する。
- 特定のドキュメントの変更が検出されたときに、通知を送信し、例えば専門家による監査プロセスを開始する
変更フィード
変更フィードは、データベース内のドキュメントに加えられた変更のソートされたリストを返します。
APIエンドポイント
変更フィードは、データベース内のドキュメントに加えられた順序づけられたリストを返すREST APIエンドポイント/{tkn-db}/_changesとして実現されています。
これにより、アプリケーションはドキュメントの変更に反応するビジネスロジックを実装できます。
接続方法
変更フィードに接続するには、次の方法があります。
ポーリング（polling）
デフォルトの方式です。リクエストに対して、変更のリストを返します。次の一連の変更を取得するには、新しいリクエストを送信する必要があります。
ロングポーリング(longpol)
通常のポーリングに加えて、リクエストが特別なlast_seqパラメータで送信された場合、新しい変更が発生して投稿されるまで、リクエストは開いたままになります。
連続（continuous）
継続的変更APIを使用すると、変更通知が届いたときに、単一のHTTP接続で受信できます。継続的変更APIにリクエストを送信すると、クライアントとSync Gatewayの両方が接続を「永久に」開いたままにします。
WebSocket
WebSocketモードは概念的には連続モードと同じですが、実際のモバイルの多くのユースケースで連続モードが失敗する原因となるプロキシサーバーとゲートウェイの問題を回避することができます。
WebSocket
継続的なストリーミングHTTP応答は、すべての展開に適しているとは限りません。一部のプロキシサーバーは、チャンクモードの応答解析を実行します。チャンクモードの応答解析では、応答全体がバッファリングされるのを待ってから送信します。したがって、継続的なフィード応答が終了することはないため、クライアントに何も送信されません。この問題は、WebSocketメソッドを使用して回避できます。
クライアントは、クエリパラメーターをwebsocketに設定し、APIエンドポイントのURLへのWebSocket接続を開くことによってWebSocketを要求します。
オプションの指定
接続が開いた後、クライアントはフィードオプションを指定してサーバーに単一のテキストメッセージを送信します。このメッセージは、_changesへの通常のHTTP POSTの本文と同じです。つまり、キーがパラメーターであるJSONオブジェクトです（たとえば{"since": 112233, "include_docs": true}）。
使用するクライアントに応じて、オプションがバイナリとして送信される場合があります。
メッセージ
サーバーがオプションを受信すると、テキスト形式のメッセージの送信を開始します。メッセージはJSONです。それぞれに、配列でラップされた1つ以上の変更通知（通常のフィードと同じ形式）が含まれています。
次の例を参照してください。
[ {"seq":1022,"id":"beer_Indiana_Amber","changes":[{"rev":"1-e8f6b2e1f220fa4c8a64d65e68469842"}]},
{"seq":1023,"id":"beer_Iowa_Pale_Ale","changes":[{"rev":"1-db962c6d93c3f1720cc7d3b6e50ac9df"}]}
]
空の配列は特殊なケースです。これは、この時点でフィードが既存のリビジョンのバックログの送信を終了し、新しいリビジョンが作成されるまで待機することを示します。したがって、クライアントがデータベースの現在の状態に「追いついた」ことを示します。
このwebsocketモードはcontinuousモードと同じように動作します。通知のバックログ（存在する場合）が送信された後、接続は開いたままになり、新しい通知が発生すると送信されます。
圧縮フィード
フィードは圧縮形式で送信できます。これにより帯域幅が大幅に減少します。
クライアントは、圧縮されたフィードを受け入れることを通知するために、送信する最初のメッセージのフィードオプションに"accept_encoding":"gzip"を追加します。
Webhook
Sync GatewayのWebhookイベントハンドラーは、ドキュメントフィルタリングとHTTP POST操作の両方を非同期で実行します。
これによって、以下の影響を最小限に抑えることができます。
- Sync Gatewayの通常の処理に対するパフォーマンスの影響
- HTTP POST操作からの遅い応答時間によって消費される同期ゲートウェイノードのCPUリソースの量。
機能
Webhookはレプリケーションのプッシュサイクルで機能します。
Sync Gatewayは、Couchbase Serverバケット内のドキュメントを更新するたびdocument_changedに、イベントキューにイベントを追加します。これらの変更は、Sync GatewayのパブリックREST APIおよびCouchbase Liteプッシュレプリケーションから発生する可能性があります。
イベントキューにdata_changedイベントが含まれている場合は、Sync Gatewayは次のプロセスを生成します。
-
FILTER: 投稿する変更済みドキュメントを決定します。イベントプロセスは、ドキュメント変更に際してでWebhookのイベントハンドラー（FILTER）を実行します。FILTERは、POSTする必要のあるドキュメントを決定します。FILTERがない場合、すべてのドキュメントの変更はPOSTに渡されます。
-
POST: 変更されたドキュメントをURLエンドポイントに送信します。
FILTERによって選択されたドキュメントの変更を定義済みのURLにPOSTするために、HTTP/HTTPSが使用されます。
複数のWebhookイベントハンドラーを定義できます。たとえば、さまざまなフィルタリング基準を使用してWebhookを定義し、変更されたドキュメントをさまざまなURLに投稿できます。
サンプルWebhook定義
このwebhookイベントハンドラーの例では、フィルターのない単一のインスタンスを定義します。document_changedイベントをリッスンし、変更されたドキュメントをすぐにURLhttp://someurl.comに送信します。
"event_handlers": {
"document_changed": [
{
"handler": "webhook",
"url": "http://someurl.com"
}
]
}
プロパティ
イベントハンドラー定義は、次のプロパティで構成されています。
フィルター
プロパティ名：this_db.event_handlers.document_changed.filter
フィルターは、投稿するドキュメントを決定するために使用されるJavaScript関数です。ドキュメント本体を入力として受け入れ、ブール値を返します。
フィルター関数がtrueを返す場合、Sync Gatewayはドキュメントを投稿します。
フィルター関数がfalseを返す場合、Sync Gatewayはドキュメントを投稿しません。
フィルター機能が定義されていない場合、Sync Gatewayは変更されたすべてのドキュメントを投稿します。
フィルタリングは、投稿するドキュメントのみを決定します。ドキュメントから特定のコンテンツを抽出して投稿するのではありません。
イベントハンドラタイプ
プロパティ名：this_db.event_handlers.document_changed.handler
イベントハンドラーのタイプを設定します。現在、これはwebhookである必要があります。
タイムアウト値
プロパティ名：this_db.event_handlers.document_changed.timeout
POST操作への応答を待機する時間（秒単位）を設定します。これにより、実行速度の遅いPOST操作によってWebhookイベントキューがバックアップされないことが保証されます。タイムアウト制限に達すると、Sync Gatewayは応答のリッスンを停止し、操作を破棄します。
パフォーマンスを調整するためにデフォルト設定を調整する必要はありません。
URL
プロパティ名：this_db.event_handlers.document_changed.url
ドキュメントが投稿されるアドレスを設定します。
イベント処理プロパティ
並行プロセス数最大値
プロパティ名：this_db.event_handlers.max_processes
同時に処理できるイベントの最大数を設定します。
ほとんどの場合、デフォルト値でうまく機能するはずです。パフォーマンスを調整するために調整する必要はありません。ただし、頻繁なWebhook投稿が確実に送信されるようにするために、十分に高い値に設定することが考えられます。
キュー待機時間
プロパティ名：this_db.event_handlers.wait_for_process
イベントキューがいっぱいのときにイベントを受信した場合に、イベント処理が空きプロセスを待機する最大時間（ミリ秒）を設定します。
パフォーマンスを調整するために調整する必要はありません。
通常のSync Gateway処理を優先して、ブロックを回避するために、ゼロ値を設定することが考えられます。この場合、キューがいっぱいの間に到着したイベントは、すぐに破棄されます。
関連情報