web-dev-qa-db-ja.com

RavenDb-REST WebAPIを介してデータを取得します

RavenHQ-cloud-databaseからデータを取得する必要があるRESTfulAPIを構築したいと思います。まず第一に、これは可能ですか？

アイデアは、複数のアプリケーション（xamarin-app、mvc-appなど）を用意し、構築しているAPIを使用してそれらのアプリケーションにデータを渡すことです。

たとえば、ボタンが1つあるモバイルアプリがあるとします。

  1. ユーザーがボタンをクリックする
  2. クライアントは私のAPIのGet（）エンドポーリングに接続します
  3. APIを介して、RavenDBにリクエストした特定のデータを返します
  4. APIからモバイルアプリにデータを送信します（たとえば、JSONを介して）
  5. 私のアプリでそのデータを使用してください。

APIを介してデータベースにGet（）を実行するたびに、少量のデータを取得する必要があります。しかし、データベースは全体として非常に大きいので、データベース全体をモバイルアプリに保存するのは良いアプローチではないと思います。 APIを介して必要なときに、少量のデータを取得することをお勧めします。

また、さまざまなアプリケーションでdb-dataを使用する必要があるため、これが最善のアプローチです。

このアーキテクチャはそれを解決するための良い方法ですか？

databaserestapiravendb
1
user3228992

RavenDB（RavenHQはホストされているRavenDB）は、作成したAPIを含め、あらゆるデータシステムの永続ストレージとして機能しますか？もちろん、機能します。それはドキュメントデータベースです。それがその仕事です。

「RavenDBとは何ですか？」と尋ねない限り、何を求めているのか正確にはわかりません。もしそうなら、私は ravendb.net のマーケティング資料とドキュメントを読むことをお勧めします。

RavenHQはRavenDBをホストしているだけなので、Amazon、Azure、またはその他のクラウドプロバイダーでRavenDBインスタンスを直接ホストするのと同じです。

私が言えるのは、あなたが本当に質問している理由です。クラウドでホストされたストレージを使用するシステム（この場合はAPI）を作成できるかどうかを知りたいということですか？もしそうなら、答えはイエスです。

クラウドでホストされるストレージはローカルストレージのように機能しますが、待ち時間が長くなります。設計でより長い応答時間を計画し、ネットワーク接続の障害を適切に処理する限り（どちらも、SANまたは別のマシンでのストレージのより一般的なシナリオでも懸念されるはずです）同じLAN上で）それならそれはうまくいくはずです。

RESTについて：

どの程度厳密に従うかRESTカスタムAPIの設計ガイドラインは、完全にあなたとAPIの設計に依存します。公開することは決してないため、バックエンドストレージシステムとは関係ありません。 APIを直接介して。

モバイルクライアントの設計について：

はい、非常に大規模なデータシステムの小さなサブセットのみが必要な場合にのみ、クライアントが持つ必要のあるデータを要求することは良い計画です。

しかし、直接的なユーザーアクション（-===-）のためにネットワークを介したクエリに依存するモバイルアプリケーションが機能する場合でもcan動作しますが、私はお勧めしません次の理由によるその正確なアプローチ：

  • UIレイテンシー;モバイルネットワークは高速ではないため、APIとバックエンドストレージがどれほど高速であっても、UIはブロックされたまま応答を待ちます。その応答サイクルとクライアント処理が500ミリ秒未満で完了したとしても、それでもUIには十分な速度ではありません。
  • ネットワークアクセスは常に必要です。モバイルアプリはオフラインで動作する必要があることが多く、このソリューションはそれを禁止します
  • バッテリー寿命とデータ使用;ユーザーが同じデータを何度も要求した場合は、無線をオンにしておく必要があり、ユーザーのデータプランを必要以上に使用する可能性があります
  • 負荷;ユーザーの使用パターンによっては、サーバーの負荷が非常に「バースト」します。システムがどの程度適切に設計されているか、データの形状、作成するクエリ、ユーザーがシステムを使用するタイミングなどによっては、APIが警告なしに簡単に圧倒される可能性があります。

上記の問題の多くを修正する方法は、アプリのキャッシュレイヤーを介してリクエストを行うバックグラウンドタスクを使用することです。次に、APIがそのレイヤーによって適切にキャッシュされる可能性のある応答を返すこと、およびそのキャッシュを最新の状態に保つことを処理することを確認します。

（API、RavenDB、したがってRavenHQにそのキャッシングを実装する場合、キャッシングシステムは非常に優れているため、正しく使用すれば問題はありません。「独自に設計できますか」という質問になります。 APIから正しくキャッシュしますか？」）

また、オフラインでの使用を可能にするために（ユーザーが最初にオンラインでデータを取得できると仮定して）、第1層キャッシュが使用するのと同じキャッシュシステムを使用して、ローカルデータベースにさらにキャッシュする第2層キャッシュを追加できます。

上記のクライアント設計の問題はいずれも、バックエンドストレージの選択を気にしません。さまざまなクライアント設計とAPI設計の設計者が、これらのシステムがどの程度うまく連携するかを決定します。

1
Mufasa