Apollo GraphQL リゾルバーで使用される親パラメーターと、Mongoose モデルを結合するための MongoDB 集約の $lookup ステージで使用される親パラメーターの比較

Question

Apollo GraphQL と Mongoose を使用してバックエンド アプリケーションを開発しています。 User と Post という 2 つのモデルがあり、これらは 1 対多の関係になります (1 人のユーザーが複数の投稿を持つことができますが、1 つの投稿は 1 人のユーザーに属します)。

GraphQL スキーマの User フィールドをクエリして、ユーザー ID ごとにユーザーとそのユーザーに属するすべての投稿を取得したいと考えています。また、投稿タイプの作成者フィールドをクエリして、投稿を書いたユーザーを取得したいと考えています。

MongoDB の異なるコレクションからデータを結合するには、Apollo GraphQL リゾルバーの親パラメーターを使用する方法と、MongoDB 集約の $lookup ステージを使用する方法の 2 つがあることを学びました。

親パラメータは、親フィールドのパーサーから返された結果を含むオブジェクトです。親パラメーターを使用すると、親フィールドまたは型のデータにアクセスし、それを子のフィールドまたは型に渡すことができます。たとえば、これを使用して、次のようにマングース モデルを結合できます。

type User {
  やった！
  名前: 文字列
  投稿: [投稿]
}

投稿タイプ {
  やった！
  タイトル: 文字列
  著者: ユーザー
}

タイプ クエリ {
  user(id: ID!): ユーザー
}

const リゾルバ = {
  ユーザー: {
    投稿(親、引数、コンテキスト) {
      return context.db.Post.find({ author:parent.id });
    }、
  }、
};

$lookup ステージは、同じデータベース内の別のコレクションへの左外部結合を実行する集計パイプライン ステージです。 $lookup ステージを使用すると、複数のコレクションのデータを 1 つの結果セットにマージできます。たとえば、これを使用して次のようにモデルを結合できます。

db.posts
  。集計（[
    {
      $lookup: {
        送信者: 「ユーザー」、
        localField: "著者"、
        外部フィールド: "_id"、
        として: 「著者」、
      }、
    }、
  ])
  .toArray((エラー、投稿) => {
    console.log(投稿);
  });

自分のアプリケーションにどれを使用すればよいかわかりません。より効率的で、スケーラブルで、保守可能なオプションを選択したいと思いました。

Apollo GraphQL リゾルバーで親パラメータを使用する場合と、MongoDB 集約で $lookup ステージを使用して Mongoose モデルに結合する場合の主な違いとトレードオフは何ですか?

Answer 1

最初の手法をお勧めします。これは間違いなくクリーンで、 おそらく 高速です。 RDB の外部キーのインデックスを作成するのと同じように、author フィールドのインデックスを必ず作成する必要があります。

Answer 2

2 つの方法にはいくつかの違いがあります

パーサーを使用する

このアプローチはより直観的で読みやすいため、特に複雑なクエリの場合、保守が容易であると思います。

ただし、ネストされたフィールドごとにデータベースへの追加呼び出しが行われるため、大量のデータを処理する場合は最も効率的ではない可能性があります。これは、多数の複雑なネストされたクエリを処理する場合、パフォーマンスのボトルネックになる可能性があります。

$lookupを使用する

一方、$lookup 操作は、単一のデータベース呼び出しを使用して接続してデータを取得するため、一般にパフォーマンスが高くなります。

ただし、クエリが複雑になると、$lookup 操作が複雑になり、読み取りや保守が困難になる可能性があります。 MongoDB クエリ言語についてのより多くの知識が必要になる場合があり、パーサー アプローチほど単純で使いにくい場合があります。集計が適切に記述されていないと、パフォーマンスの問題が発生する可能性があるため、自分が何をしているのかを完全に確認してください。

したがって、あなたの例では、パーサーアプローチを使用しても構いません。たとえ集計を使用した方が高速であっても、最初のアプローチの方が読み取り/改善/保守が簡単です。

＃＃＃それが役に立てば幸い：）＃＃＃