Saving "Common" MongoDB Elements in an Application with RESTful API

Question

I am creating an application in which users can share articles.

Currently, when a user shares an article , he adds the article identifier of the common element to an array called shares on user .

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

However, since I need a way to request common elements for several user identifiers (similar to a news type request), I decided to go the way of creating a separate collection for common elements only.

 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 } }; 

To tie this together in my application code, when user updated, it is checked whether the sharedItems array in user been updated - if so, the task is delegated to shares to add or remove any matches, respectively. I did this because when a user shares an element, my client application only needs to worry about making a POST request to the user resource, instead of making a POST to the user and share resources. The problem is that I rely on replication, and I worry that for various reasons there may be some inaccuracies.

The need for a sharedItems array in a user object is that when any articles are loaded, my application must determine which items were shared by the logged-in user. My application analyzes the response for each loaded article and checks if the current user this article ID in his sharedItems array - he adds the isShared property to the article.

The only alternative to achieving all this that I can think of would be to remove the sharedItems array from the user schema and add some authentication to my API so that the GET requesting the article resource will know who the current user is, and thus my internal server can worry about checking if the current user has provided the article that was sent in the response, instead of doing client-side parsing.

The problem with this is that I do not want my API to require authentication. Articles should be accessible to all users who are logged in or out ( GET on the article resource). However, I want users to be able to publish articles ( POST in the share resource or currently POST ) to the user resource, which delegates the creation / deletion of shared documents).

How would you handle this in terms of MongoDB collections and schemas?

Answer 1

I would suggest the shareCount field in the GET /article resource (to prevent unauthorized exposure), and then use the asynchronous (and authenticated) API call to GET /user , which you can use to mark articles as common after bootstrapping.

If you do this, your GET /article resource does not need to do any additional work behind the scenes, and each request will receive the same information (with shareCount ). Only when the user logs in does your design even take care to mark something as general.

Answer 2

I would not keep sharedItems in userSchema if you are worried you cannot sync them. Just keep sharedSchema up to date. It doesn't seem like a secret that someone shared the article, so you can include the current user ID in the request to GET the article without authentication and tell the background server if the specified user has shared the article,

If you want to try to keep secret information about a secret, then you can add optional authentication to the GET API and only return information about access to the authenticated user, but return the rest of the article regardless of authentication. Or you can build a sharedItems array on the back of sharedSchema when you request user information and include it in the response.