私はプロジェクトを開始していますが、バケットシャドウイングではなく、モバイルANDサーバー（バックエンド）アプリケーションからの同期ゲートウェイREST API呼び出しを使用する必要があることが多く説明されています。しかし、Sync Gatewayは、特に動的クエリを使用してクエリを実行すると、かなり迷惑になります。私の考えは、書き込み用にSync Gatewayを使用し、読み込み用にNodeJS SDKを使用するバックエンド・アプリケーション用の小さなモジュールを作成することです。このようにして、（Sync Gatewayで厄介なことをするのではなく）取得/クエリにN1QL、ビューなどを使用できるようになり、データの書き込みが正しく行われているかどうかを確認できます。Couchbase Sync Gatewayクライアントとサーバー側
私の考えはここには欠陥がありますか？誰もこのアプローチの問題を予見できますか？
NodeJS SDKを使用して同期ゲートウェイバケットに直接接続することは何もありません。ただし、バケットのJSONコンテンツは公開されておらず、将来のリリースで変更される可能性があります。
2014年6月からこのフォーラムのスレッドは、ご自身の責任で、このアプローチが実現可能であることを暗黙の承認を与える：https://groups.google.com/forum/#!topic/mobile-couchbase/OeTk1fzYJvE
私は同期のゲートウェイと対話するための主なパターンはチャンネルに加入するには、サーバーのコードのためだと思います、それが見ている変更に基づいてドキュメントを突然変更することがあります。場合によってはマップの縮小クエリが出てくると私の意見では、ゲートウェイバケツに対してそれらを実行し、バケツのシャドウイングのオーバーヘッドを完全に避けることは大丈夫です。 Sync Gatewayのデータレイアウトが将来変更される可能性があることを理解している限り、私たちは、Couchbase Serverに保存したJSONをパブリックAPIとはみなしません。
今あなたは、このようなあなたのマップ機能をラップしたいと思います：
function(doc, meta) { if (doc._sync && !doc._deleted) { emit(doc.foo, null); } }
アプローチは、同期のゲートウェイ文書を除外するためのフィルタを使用してビューを定義することです。ただし、上記の警告は引き続き適用されます。同期ゲートウェイは、将来のリリースでドキュメントをどのように表現するかを変更する可能性があります。
また、同期ゲートウェイバケットでN1QLクエリを詳述する別のSO回答も見つかりました：https://stackoverflow.com/a/37036363
NodeJS SDKはバケットシャドウイングを使用する以外は、同期ゲートウェイバケットにアクセスできませんが、これはお勧めできません。
Couchbaseモバイルを使用しない場合は、CouchbaseサーバーとNodeJS SDKをサーバー側に活用し、独自のモバイル用REST APIを作成することで、同期ゲートウェイを使用しないでください。