DEV Community: Darnell

Designing a database for a social media app

Darnell — Sun, 30 Mar 2025 07:10:46 +0000

Making clones of websites and recreating their functionality is a good way to develop skills and even challenge oneself in ways you may not have expected to. So as a challenge to myself, I decided to create a clone of the social media website, Tumblr. I chose Tumblr because it's the social media website that I've used the most.

The Planning Phase

The biggest mistake to make with any large project is to open VSCode and stare at your code editor for a while, wondering where to begin (and often times even rewriting code you just wrote after realizing what else needs to be done). The best way to start a project like this is to ask questions about what needs to be done, how the web app is supposed to behave for users. Having a full plan reduces roadblocks and gives you a clear map of what your end result is supposed to be.

Some questions I had to ask myself:

How to handle user authentication?
What will my routes look like, and what data will they require / send to the user?
What are the most important features for my clone website (an important question, as I'm only one person. Tumblr as a whole is managed by hundreds of employees)
What persistent data will I need to handle?

For the sake of this article, I'll only focus on the answer I came up with for the last one for now.

What persistent data will I need to handle?

Users

Users need a username.
For their credentials, I'll need to store their email address and their (hashed) password.
Users should be able to customize their profiles. Unlike the above two, this is optional. Users can save some info about themselves in an "About" section. They can also save a header image for their blog, and a profile image. For this project, I won't store the images in my database. I'll use cloudinary for that, and I'll store the links to the images (and the image ids) in my database instead.

Posts

Here's where things got complicated. Tumblr has a reblog feature, which allows users to share posts from other blogs to their own. They can't edit content written by other users, but they can add their own content to posts. Reblogged posts are brand new posts that "belong" to the one reblogging. So I'll need to replicate that functionality.

Another thing to consider is how shared posts function when the original poster edits them. Imagine if someone made a post saying "I love cats". A thousand other users can share / reblog these posts, only to have this post suddenly change on them when the original poster edits the post to say, "I hate cats" instead. Tumblr doesn't allow this behavior, and editing a post will only edit that post for the specific user.

There's also the matter of post content. Posts on tumblr can be made up of text, music, videos, photos, or links. Then you need a way to manage which part of a post was created by which user, as well as what type of content the post contains.

My solution to this involved breaking posts down into segments. A post could be made up of several segments, which would be responsible for the post content. And the content would be displayed in order of when the segment was created, starting with the oldest segment.

This allows me to simplify the posts themselves. Now I just need to care about the following

When was a post created? (a timestamp)
Who made the post? (Its author)
If the post is a reblog, what is the original post?
If the post is reblog, what post was it immediately reblogged from?

Segments

As said above, segments will be responsible for the actual post content. Whenever a user creates a new post or adds content to a reblogged post, they create a post segment. Whenever a user edits a post, they will only be able to a segment that they themselves have created. As far as Segment data goes, I'll need:

The segment author
When the segment was created
What type of content a segment holds (text, audio, video, etc). This is so the front end knows how to render the content. Tumblr allows users to mix and match post types, so I could technically use JSON to store post segment types. But I decided to keep it simple
The content of the post segment

Replies

Users can leave comments, or replies, on posts. Fortunately, tumblr keeps this pretty simple. Replies can only be text. So there isn't much to track here aside from:

Who made the reply
The content of the reply
The post the reply is being made on

Relations

Now it's important to figure out how all of this data is supposed to relate to each other.

Users -> Posts: One to many relationship. Users can create multiple posts. Each post is only created by one user.

Users -> Segments: This is the same relationship as users to posts.

Posts <-> Segments: Many to many relationship. A post can be made up of multiple segments. Segments can be associated with multiple posts via reblogging.

Posts <-> Tags: Many to many relationship. A post can have several tags. And the same tag can be associated with multiple posts.

Users following Users: Every social media site needs to have a follow feature! Users can follow many users, and users can be followed by many other users.

Users liking Posts: Users can like many posts. Posts can be liked by many users. This is another many to many relationship. For reblogged posts, likes are shared between them and the parent post.

Post -> Replies: Posts can have many replies, but replies are unique to one post. This is a one to many relationship.

After all of this, we can now decide what our database schema is going to look like.

This is just one of many steps. In my next post, I'll delve into using an ORM, writing tests, and creating my routes and controllers.

A quick guide on closures

Darnell — Tue, 12 Sep 2023 21:46:45 +0000

Closures are a powerful tool in JavaScript. If you've been writing event listeners, your own custom hooks, or even using the default hooks React is built with, then you've been using closures already. But what specifically are closures? I'll attempt to explain what they are in this post.

Scope

In order to understand closures, we need to understand scope. To summarize, when something is locally scoped, it can only be "seen" by other things within its scope. If I declare a local variable inside of a code block, then it can't be seen by anything outside of that block.

function localBlock() {
  const x = 4
  console.log(x) //this prints 4
}

console.log(x) //x is undefined

In human terms, this is kind of like entering a soundproof room with your friend and telling them a secret. No one outside of the room will hear or know it.

Closures

With scopes out of the way, we can focus on the reason I'm making this post. Closures are a way for JavaScript to "remember" or "preserve" variables that are no longer in scope. Let's consider the following code.

function outerScope(){
  const x = 100
  const innerScope = function(){
    console.log(x)
  }
  return innerScope
}

console.log(x) //prints undefined
const closureExample = outerScope()
closureExample() //prints 100

The function outerScope defines two variables. It assigns x the value of 100, and innerScope the value of a function. It then returns the function, which still has access to x.

The function innerScope technically has access to everything that was defined inside of outerScope

In human terms, I'll reuse the secret room analogy from before. You and your friend enter a soundproof room and you tell them a secret. Nobody outside of the room knows what the secret is. But your friend will still know the secret even after they've left the room and they're free to tell whoever they want.

What are closures used for?

In the beginning of this post, I named some ways in which you may have been using closures already. Closures are also used for currying / nesting functions, factory functions, and partial applications.

As a (somewhat contrived) example, let's say you're writing a small game in React. You have a button a user can click to increment a counter. After 5 seconds have passed, an alert box pops up to show the user how many times they clicked the button. The code would look something like this.

function App(){
  const [counter, setCounter] = useState(0)
  const increment = () => setCounter(c => c + 1)

  useEffect(() => {
    setTimeout(() => alert(`You clicked the button ${counter} times!`), 5000)
  }, [])

  return (<div>
      <button onClick={increment}>Counter: {counter}</button>
  </div>)
}

const root = ReactDOM.createRoot(document.querySelector("#root"))
root.render(<App/>)

In this example, the anonymous function we passed to setTimeout contains a closure around the initial value for counter. No matter how many times we click the button, the alert box will tell us You clicked the button 0 times! So when our app component mounts, the useEffect function runs, and our anonymous function that we passed to setTimeout "remembers" the value for counter.

Extra: Why this happens and fixing our component

If you're wondering why useEffect doesn't work the way you want it to, it's because of how React hooks handle state. State is never mutated. React really doesn't want us to do this. When we update state with our setCounter function, we're creating an entirely new value altogether. This new value isn't tracked by the function in our useEffect at all.

To fix this, we would some way to track our value without mutating our state. Fortunately, the useRef hook allows us to do just that. To keep things brief, the useRef hook creates an object with a current property. We'll assign the current property to our counter variable. The object created by useRef CAN be mutated, so we never have to worry about losing the value we assign to it. Every time we click the button, our component re-renders and our countRef object's current property is assigned the new counter value.

function App(){
  const countRef = React.useRef()
  const [counter, setCounter] = React.useState(0)
  const increment = () => setCounter(c => c + 1) 

  countRef.current = counter

  React.useEffect(() => {
    setTimeout(() => alert(`You clicked the button ${countRef.current} times!`), 5000)
  }, [])

  return (<div>
      <button onClick={increment}>Counter: {counter}</button>
  </div>)
}

const root = ReactDOM.createRoot(document.querySelector("#root"))
root.render(<App/>)