7

私は初めてでCouchDb、それを適切に利用する方法を理解しようとしています。私はいつも Web レイヤーを作成し、それを mongo の前に配置して、ユーザーがその中のデータにアクセスできるようにするところから来てMongoDBいます。私が今まで書いてきたウェブサイト。Couch を見ると、ネイティブ API が HTTP であり、OAuth サポートなどの機能が組み込まれていることがわかります。また、Couch の前にコード層を配置する必要がなくなったことを示唆するその他の機能が組み込まれています。書きますViewsCouch のアカウントをユーザーに配布するだけですか? 私は、私のサイト用の HTTP ベースの API や、ユーザーが私のデータを消費するようなものについて考えています。しかし、このようにCouchを開くのは奇妙に思えます。Couch の意味での OAuth は、自分のネットワークの内部で「公式に」作成して実行するソフトウェアのリモート アクセスを意味しているのでしょうか、それとも文字通りエンド ユーザーを対象としているのでしょうか?

API リクエスト中にデータベースに関連しない追加の処理が必要な場合など、CouchDB 上のコード レイヤーを介してのみ実行できる処理が存在する可能性があることはわかっています。したがって、これらの線に沿って考えると、とにかくコードレイヤーが必要になると思います。

4

2 に答える 2

4

ディーラーの選択。

Nodejitsu には、この種のトピックに関する優れた記事があります。

アプリケーションの詳細がわからないので、幅広いアプローチをとります...

バックエンド

ユーザーがデータベースを見るのを防ぎたい場合は、バックエンドにします。node.js のようなものを介してすべてをパイプし、ユーザーが見る必要があるものだけを提示することができ、ユーザーはデータベースについて何も知りません。リソース ビュー プレゼンターを参照してください。

フロントエンド

データのセキュリティを気にしなければ、アプリ全体を CouchDB でホストできます。CouchAppを参照してください。このアプローチには、レプリケーション メカニズムを使用してサイト/データの公開を制御できるという利点があります。ここでの欠点は、ほとんどの場合、CouchDB をバックエンドに近づける必要があるいくつかの技術的な制限に遭遇することです。

ブレンド

アプリ サーバーにインターフェイスを提示させ、クライアントにデータベースからデータを個別にプルさせます。これにより柔軟性が最大になりますが、設計が優れていてもサポート性とスケーラビリティの問題が発生する可能性があるため、問題が生じる可能性があります。

私のおすすめ

バックエンドで CouchDB を使用します。モバイル クライアントを同期する必要がある場合は、この目的のために公開されているセカンダリ DB を使用し、このデータを必要な場所に選択的に同期します。

于 2012-12-11T03:29:26.293 に答える
1

簡単に言えば、いいえ。

一般向けのサイトで Couch を適切に保護する方法はありません。十分に細かいレベルでアクセスを区別する方法はありません。いずれかのデータにアクセスできるユーザーは、すべてのデータにアクセスできます。

サイト上のすべてのデータが公共の消費を意図しているわけではありません。最も些細なサイトを除きます。

于 2012-12-11T06:33:04.407 に答える