The problem domain: Social media project - MongoDB Tutorial

- [Instructor] Before we dive into the full course, let's have a quick look at the application we're going to be modeling data for. We're going to work out the modeling or at least the potential modeling for a social media site. Now, whether it's LinkedIn or Facebook or Twitter or something else, they all share some very common use cases. In our application, we're going to focus on three main parts which really drive the entire application. If you've used any social media, these should be pretty familiar to you. We'll start out with the user. Now we know that users have information stored about them. In the case of LinkedIn, for example, we have their name, their icon, their job title, a list of experience all the jobs where they've worked a list of their skills and other sort of resume information. All the things you'd normally expect to know about a person, all their static properties. Now, from the social media standpoint there's a lot more to unpack here. And first, if you went to a user's profile page you'd probably expect to see, like you do on the left here, a list of all the posts that they've made. So on the left, our activity is all the posts and replies that this user has made, from themselves, Okay. On the right hand side, you'll see that user's feed, which would be the way that user would see their own homepage. So in other words, if you come to one person's homepage you'll see all of their posts. When they go to their own homepage they're going to see all the posts from all their friends and all their friends, friends, and all the replies. It's a way to sort of split out the way that we consume this information. In both cases, we have a list of posts and in both cases the post is the same, but it's really complicated. If you dig into what a post is, right? A post has title, content, links, authors, dates. It's all pretty static information. But they also have dynamism, a running count of likes and shares and other interactions. Not to mention threads, where each post is attributed to a different user and has its own set of likes and shares and interactions and a reply thread. There's a lot to examine here and we'll be able to look into all the hurdles surrounding modeling this out. Especially when we think about this in a non-relational way. Now remember, no SQL databases like Mongo DB want you to work with a document centric view. The document should contain all the data that we need and act as a single source of truth for the UI. It's going to be tough, cause we can already see some one to one, one to many and many to many relationships here on these pages. This is going to provide for us some interesting challenges on the data modeling side of this to be sure.