4

ユーザーが記事を共有できるアプリケーションを作成しています。

現在、 が をuser共有すると、共有アイテムの ID が で呼び出される配列にarticle追加されます。articlesharesuser

var userSchema = {
  // `sharedItems` is a list of article IDs that the user has shared
  sharedItems: { type: Array }
};

ただし、複数のユーザー ID について共有アイテムを照会する方法が必要なので (ニュース フィードの一種のクエリに似ています)、共有アイテム専用の別のコレクションを作成する方法に進むことにしました。

var shareSchema = {
  // The ID of the user who shared the article
  userId: { type: String },
  // The ID of the article shared
  articleId: { type: String },
  dateCreated: { type: Date }
};

アプリケーション コードでこれを結び付けるために、 aが更新されると、 の配列が更新されuserたかどうかがチェックされます。更新されている場合は、タスクがコレクションに委任され、一致するものをそれぞれ追加または削除します。これを行ったのは、ユーザーがアイテムを共有するときに、クライアント側のアプリケーションがリソースへのリクエストを作成するのではなく、リソースのリクエストを作成することだけを気にする必要があるためです。ここでの問題は、私が複製に頼っていることであり、さまざまな理由で不正確な点があるのではないかと心配しています.sharedItemsusersharesPOSTuserPOSTuser share

sharedItemsエンティティに配列が必要なのは、user記事が読み込まれたときに、ログインしているユーザーによってどのアイテムが共有されたかをアプリケーションが検出する必要があるためです。私のアプリケーションは、ロードされたそれぞれの応答を解析し、現在の配列にその ID があるかどうかを確認します。ある場合は、のプロパティを記事に追加しarticleます。userarticlesharedItemsisShared

このすべてを達成するための他の唯一の代替手段 (私が考えることができる) はsharedItems、ユーザー スキーマから配列を削除し、何らかの認証を API に追加して、リソースGETへの要求が現在のユーザーを認識できるようにすることです。ユーザーは、したがって、私のバックエンドは、クライアント側で解析を行う代わりにarticle、現在のユーザーが応答で送信されたを共有しているかどうかを確認することを心配できます。article

これに関する問題は、API で認証を要求したくないことです。記事は、(リソースGET上で)ログインまたはログアウトしているすべてのユーザーがアクセスできる必要があります。articleただし、ログインしたユーザーのみが記事を共有できるようにしたい(POSTリソースshare、または現在、共有ドキュメントの作成/削除POSTuser委任するリソースに)。

MongoDB のコレクションとスキーマに関して、これをどのように処理しますか?

4

2 に答える 2

0

同期を保つことができないと心配している場合はsharedItems、そのままにしておく必要はありません。最新のuserSchema状態に保つだけです。sharedSchema記事を共有したのは秘密であるべきではないように思われるので、現在のユーザー ID をリクエストに含めて、認証なしで記事を取得し、指定されたユーザーが記事を共有したかどうかをバックエンドに通知させることができます。 .

共有情報を秘密に保ちたい場合は、オプションの認証を GET 記事 API に追加し、認証されたユーザーに関する共有情報のみを返し、認証に関係なく残りの記事情報を返すことができます。または、情報を要求したときにsharedItemsバックエンドで配列を構築し、それを応答に含めることができます。sharedSchemauser

于 2013-05-30T05:09:24.253 に答える