Parse.com Database design for likes/comments`

1
votes

I am working on an application which will have users.. who create posts.. and other users can like/comment on any post.

I am trying to figure out a best way to design db tables for this. I have read the anypics tutorial on parse.com site. They keep all comments and likes in a table called "Activity". (which makes sense) being able to query any type of activity (like/comment) from a separate table without having to touch "posts" table.

My question is- in this scenario how do I fetch all posts that current user created along with likes and comments on each those posts?

Anypic app by parse makes a separate request to fetch number of likes on each post (which I think is not ideal.) I am new to nosql data stores.. so if someone could help me out with suggestion on how to structure data that would be great.

Also, how bad is it to store all likes/comments as an array in the post itself? I think this won't scale but I might be wrong.

Thanks

1
mongodbdatabase-designparse-platformdatabase
Are you asking how to do it in general with any no-sql database, or is it specific to Parse and how you would do it using their service (e.g. avoiding the extra request to get like count). - Timothy Walters
Preferably want to know how it can be done using parse. But, I am still evaluating if its a good idea to use it or not. So, if you could suggest in general that would be great. - user3264361

1 Answers

0
votes

In terms of Parse, I would use an afterSave Cloud Function to update the Post anytime a like/comment is added.

Have a look at the documentation here, in the most simple case you just create an afterSave for the Activity class that increments the like/comment count.

In a more advanced scenario you might want to handle update/delete too. E.g. if someone can change their 'like' to 'not like' you would need to look at the before/after value and increase/decrease the counter as needed.

I am a fan of storing extra 'redundant' data, and no-sql/document-db systems work well for that. This is based on the idea that writes are done infrequently compared to the number of reads, so doing some extra work during/after the write has less impact and makes the app work more smoothly.