From React to MongoDB: How I Learned Backend Design (The Hard Way) — A Frontend Engineer's Journey

Two weeks ago, I was a React developer who thought backend was just "API that returns data."

I started building a social media project and hit two problems that made me realize how little I actually knew.

This is me documenting that journey — what confused me, what I got wrong, and what finally clicked. If you're transitioning from frontend too, you'll probably face the same "wait, what?" moments.

The First Problem: Embedding vs Referencing

Even coming from a frontend background, I knew some backend basics. Enough to feel confident. Enough to think "I got this."

Then I decided to dig a rabbit hole.

I started learning about data modeling and schema design. Came across terms like embedding, referencing, schema design patterns. Read about them. Understood them individually. But something still felt off, like I was missing the actual instinct of when to use which. So I decided to put my hands on a project. Learning by doing.

So there I was, building a social media app. I had three things: Users, Posts, Comments. Simple, right?

Nope.

First real decision: should I embed posts inside the user document or create separate collections and reference them?

I had genuinely no idea. Both sounded fine to me. I almost embedded everything. posts inside users, comments inside posts because that felt "organized." Like keeping things together in one place.

A senior dev would have facepalmed so hard.

Here's what was actually confusing me: I was thinking about how data looks, not how the app uses it. That's where access patterns come into play.

My frontend brain thinks in components. Keep related things together, it makes UI easier. That instinct betrayed me in MongoDB.

The real question isn't "are posts related to users?" , of course they are! The real question is:

How often do I fetch posts separately?
Will this array grow unboundedly?
Is this data shared across multiple documents?

Posts grow over time, a user could have 5 posts or 500. Embedding them inside the user document means that document gets bigger every time someone posts. As the document grows, you risk hitting MongoDB's 16MB document limit and creating performance problems long before you get there.

So I referenced them instead:

// User Schema — stores only reference IDs
const userSchema = new mongoose.Schema({
  username: String,
  email:    String,
  posts:    [{ type: mongoose.Schema.Types.ObjectId, ref: "Post" }]
})

// Post Schema — stores who created it
const postSchema = new mongoose.Schema({
  user:    { type: mongoose.Schema.Types.ObjectId, ref: "User" },
  content: String,
  likes:   [{ type: mongoose.Schema.Types.ObjectId, ref: "User" }]
})

Then used populate() to fetch actual post data when needed.

The lesson:

Access patterns matter more than how data "naturally belongs together." Don't think like a UI developer. Think about how the data grows and how the app reads it with scalability in mind from the start.

The Second Problem: Pagination

Days later, I hit pagination.

I thought skip/limit was just "skip some, take some. Easy."

Nope again.

I built it and it worked. Page 1? perfect. Page 2? fine. Page 50? Suddenly the server was sweating.

Here's what I didn't understand: skip() doesn't actually skip documents. It reads them and throws them away.

So on page 50 with 10 posts per page: MongoDB reads 490 documents → throws them away → returns next 10

Every page deeper you go, more wasted reads. Performance gets worse linearly. On small datasets you never notice. On real data with thousands of posts, it's a problem!

I also got the formula wrong the first time:

const page = req.query.page || 0
.skip(page * postsPerPage)  // starts from page 0 — weird

// What actually makes sense
const page = parseInt(req.query.page) || 1
const skip = (page - 1) * postsPerPage
// page 1 → skip 0  → posts 1-10
// page 2 → skip 10 → posts 11-20
// page 3 → skip 20 → posts 21-30

Page starting at 0 works technically, but page 0 makes no sense to a user. Page 1 is natural. Small thing, real difference.

The correct implementation:

const page         = parseInt(req.query.page) || 1
const postsPerPage = 10
const skip         = (page - 1) * postsPerPage

const posts = await postModel
  .find({ user: user._id })
  .sort({ createdAt: -1 })  
  .skip(skip)
  .limit(postsPerPage)
  .lean()                   

const totalPosts = await postModel.countDocuments({ user: user._id })
const totalPages = Math.ceil(totalPosts / postsPerPage)

When does it matter? If your dataset is small, under a few thousand documents skip/limit is honestly fine. It becomes a real problem at scale, thousands of pages deep, millions of documents. That's also why many large applications eventually move to cursor-based pagination, which avoids the growing cost of deep skips entirely.

But understanding why it gets slow is what separates someone who just makes it work from someone who understands what they built.

The Bigger Lesson

These two problems taught me something I didn't expect.

Backend isn't just "make the code work." It's "make it work fast, make it secure, make it scalable."

Frontend taught me to think about UI, about the user's perspective, that 30-second first impression rule, what they see before they even read a word.

Backend is teaching me to think about data, not how it looks on screen, but how it lives in a database, how it grows over time, how the application actually uses it at scale.

Different brains. Same craft.

If You're Making This Transition Too

The confusion is normal.
The problems are common.
And the learning is real.

I'm documenting this journey as I go, not because I'm an expert, but because these are the things that genuinely tripped me up while building projects.
If sharing this saves someone a few hours of debugging, that's a win.

If you're making the jump from frontend to backend too, I'd love to hear what concepts challenged you the most. What was your first "wait, what?" moment?

推荐订阅源