{"slug": "from-react-to-mongodb-how-i-learned-backend-design-the-hard-way-a-frontend-s", "title": "From React to MongoDB: How I Learned Backend Design (The Hard Way) — A Frontend Engineer's Journey", "summary": "A frontend engineer transitioning to backend development documents the challenges of learning MongoDB schema design and pagination while building a social media app. The developer learned to prioritize access patterns over data relationships and discovered that MongoDB's skip() method reads and discards documents, causing performance degradation on deep pages.", "body_md": "Two weeks ago, I was a React developer who thought backend was just *\"API that returns data.\"*\n\nI started building a social media project and hit two problems that made me realize how little I actually knew.\n\nThis 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.\n\nEven coming from a frontend background, I knew some backend basics. Enough to feel confident. Enough to think *\"I got this.\"*\n\nThen I decided to dig a rabbit hole.\n\nI 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.\n\nSo there I was, building a social media app. I had three things: **Users**, **Posts**, **Comments**. Simple, right?\n\nNope.\n\nFirst real decision: should I embed posts inside the user document or create separate collections and reference them?\n\nI 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.\n\n*A senior dev would have facepalmed so hard.*\n\nHere'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.\n\nMy frontend brain thinks in components. Keep related things together, it makes UI easier. That instinct betrayed me in MongoDB.\n\nThe real question isn't *\"are posts related to users?\"* , of course they are! The real question is:\n\nPosts 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.\n\nSo I referenced them instead:\n\n``` js\n// User Schema — stores only reference IDs\nconst userSchema = new mongoose.Schema({\n  username: String,\n  email:    String,\n  posts:    [{ type: mongoose.Schema.Types.ObjectId, ref: \"Post\" }]\n})\n\n// Post Schema — stores who created it\nconst postSchema = new mongoose.Schema({\n  user:    { type: mongoose.Schema.Types.ObjectId, ref: \"User\" },\n  content: String,\n  likes:   [{ type: mongoose.Schema.Types.ObjectId, ref: \"User\" }]\n})\n```\n\nThen used `populate()`\n\nto fetch actual post data when needed.\n\nAccess 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.\n\nDays later, I hit pagination.\n\nI thought skip/limit was just *\"skip some, take some. Easy.\"*\n\nNope again.\n\nI built it and it worked. Page 1? perfect. Page 2? fine. Page 50? Suddenly the server was sweating.\n\nHere's what I didn't understand: **skip() doesn't actually skip documents.** It reads them and throws them away.\n\nSo on page 50 with 10 posts per page: MongoDB reads 490 documents → throws them away → returns next 10\n\nEvery 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!\n\nI also got the formula wrong the first time:\n\n``` js\nconst page = req.query.page || 0\n.skip(page * postsPerPage)  // starts from page 0 — weird\n\n// What actually makes sense\nconst page = parseInt(req.query.page) || 1\nconst skip = (page - 1) * postsPerPage\n// page 1 → skip 0  → posts 1-10\n// page 2 → skip 10 → posts 11-20\n// page 3 → skip 20 → posts 21-30\n```\n\nPage starting at 0 works technically, but page 0 makes no sense to a user. Page 1 is natural. Small thing, real difference.\n\nThe correct implementation:\n\n``` js\nconst page         = parseInt(req.query.page) || 1\nconst postsPerPage = 10\nconst skip         = (page - 1) * postsPerPage\n\nconst posts = await postModel\n  .find({ user: user._id })\n  .sort({ createdAt: -1 })  \n  .skip(skip)\n  .limit(postsPerPage)\n  .lean()                   \n\nconst totalPosts = await postModel.countDocuments({ user: user._id })\nconst totalPages = Math.ceil(totalPosts / postsPerPage)\n```\n\nWhen 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.\n\nBut understanding *why* it gets slow is what separates someone who just makes it work from someone who understands what they built.\n\nThese two problems taught me something I didn't expect.\n\nBackend isn't just *\"make the code work.\"* It's *\"make it work fast, make it secure, make it scalable.\"*\n\nFrontend 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.\n\nBackend 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.\n\nDifferent brains. Same craft.\n\nThe confusion is normal.\n\nThe problems are common.\n\nAnd the learning is real.\n\nI'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.\n\nIf sharing this saves someone a few hours of debugging, that's a win.\n\nIf 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?", "url": "https://wpnews.pro/news/from-react-to-mongodb-how-i-learned-backend-design-the-hard-way-a-frontend-s", "canonical_source": "https://dev.to/vb05/from-react-to-mongodb-how-i-learned-backend-design-the-hard-way-a-frontend-engineers-journey-23n3", "published_at": "2026-06-24 14:04:35+00:00", "updated_at": "2026-06-24 14:09:30.498488+00:00", "lang": "en", "topics": ["developer-tools", "machine-learning"], "entities": ["MongoDB", "React", "Mongoose"], "alternates": {"html": "https://wpnews.pro/news/from-react-to-mongodb-how-i-learned-backend-design-the-hard-way-a-frontend-s", "markdown": "https://wpnews.pro/news/from-react-to-mongodb-how-i-learned-backend-design-the-hard-way-a-frontend-s.md", "text": "https://wpnews.pro/news/from-react-to-mongodb-how-i-learned-backend-design-the-hard-way-a-frontend-s.txt", "jsonld": "https://wpnews.pro/news/from-react-to-mongodb-how-i-learned-backend-design-the-hard-way-a-frontend-s.jsonld"}}