Backend Development Takeaways: Server Setup, JWT Auth, MongoDB

🚀 Built a Full-Stack Photo Sharing REST API with Node.js Excited to share a backend project I've been working on — a photo sharing app built from scratch using modern Node.js practices. 🛠️ Tech Stack: Node.js + Express.js — REST API with clean layered architecture (APIs → Services → Models) MongoDB + Mongoose — NoSQL database with populate() for relational-style queries Multer + UUID — Secure file upload with unique filenames stored in /uploads dotenv — Environment-based configuration ⚙️ Key Features: User signup system with a structured User model Photo upload with image-type validation (images only) Up & Down voting system — users can upvote or downvote photos, but not both at the same time. Upvoting a photo automatically removes any existing downvote, and vice versa — handled atomically in a single MongoDB query using $push, $pull, and $inc together Toggle behavior — clicking the same vote again removes it Pagination — efficient data fetching with .skip() and .limit() Photos sorted by popularity (count descending) Populated responses returning user info with each photo 📐 Architecture: Clean separation of concerns across 3 layers — routing, business logic, and data — making the codebase scalable and easy to maintain. This project helped me go deeper into Mongoose atomic update operators, middleware chaining, and RESTful design patterns. Github:(https://lnkd.in/dQHNJ-et) #NodeJS #ExpressJS #MongoDB #Mongoose #RestAPI #BackendDevelopment #JavaScript #WebDevelopment #100DaysOfCode

I was losing 2 seconds on every API call in my MERN app. The fix was 5 lines of code. 🧵 Most devs hit this wall and never know why their Express API feels "slow" even after deployment. Not a server issue. Not a database issue. It was missing query indexing + no response caching in MongoDB + Express. 𝐓𝐡𝐞 𝐏𝐫𝐨𝐛𝐥𝐞𝐦 : Every /api/products call was doing a full collection scan on 50,000+ documents — no index, no cache. Response time: 1800–2400ms 𝐁𝐞𝐟𝐨𝐫𝐞 — 𝐬𝐥𝐨𝐰 𝐪𝐮𝐞𝐫𝐲 (𝐧𝐨 𝐢𝐧𝐝𝐞𝐱) :  𝚌𝚘𝚗𝚜𝚝 𝚙𝚛𝚘𝚍𝚞𝚌𝚝𝚂𝚌𝚑𝚎𝚖𝚊 = 𝚗𝚎𝚠 𝚂𝚌𝚑𝚎𝚖𝚊({  𝚗𝚊𝚖𝚎: 𝚂𝚝𝚛𝚒𝚗𝚐,  𝚌𝚊𝚝𝚎𝚐𝚘𝚛𝚢: 𝚂𝚝𝚛𝚒𝚗𝚐,  𝚙𝚛𝚒𝚌𝚎: 𝙽𝚞𝚖𝚋𝚎𝚛, }); 𝐀𝐟𝐭𝐞𝐫 — 𝐢𝐧𝐝𝐞𝐱𝐞𝐝 + 𝐜𝐚𝐜𝐡𝐞𝐝 (𝟓 𝐥𝐢𝐧𝐞𝐬) : 𝚙𝚛𝚘𝚍𝚞𝚌𝚝𝚂𝚌𝚑𝚎𝚖𝚊.𝚒𝚗𝚍𝚎𝚡({ 𝚌𝚊𝚝𝚎𝚐𝚘𝚛𝚢: 𝟷, 𝚙𝚛𝚒𝚌𝚎: -𝟷 }); // ✅ 𝚂𝚝𝚎𝚙 𝟸: 𝙲𝚊𝚌𝚑𝚎 𝚠𝚒𝚝𝚑 𝚗𝚘𝚍𝚎-𝚌𝚊𝚌𝚑𝚎 𝚒𝚗 𝙴𝚡𝚙𝚛𝚎𝚜𝚜 𝚛𝚘𝚞𝚝𝚎 𝚒𝚖𝚙𝚘𝚛𝚝 𝙽𝚘𝚍𝚎𝙲𝚊𝚌𝚑𝚎 𝚏𝚛𝚘𝚖 '𝚗𝚘𝚍𝚎-𝚌𝚊𝚌𝚑𝚎'; 𝚌𝚘𝚗𝚜𝚝 𝚌𝚊𝚌𝚑𝚎 = 𝚗𝚎𝚠 𝙽𝚘𝚍𝚎𝙲𝚊𝚌𝚑𝚎({ 𝚜𝚝𝚍𝚃𝚃𝙻: 𝟼0 }); 𝚛𝚘𝚞𝚝𝚎𝚛.𝚐𝚎𝚝('/𝚙𝚛𝚘𝚍𝚞𝚌𝚝𝚜', 𝚊𝚜𝚢𝚗𝚌 (𝚛𝚎𝚚, 𝚛𝚎𝚜) => {  𝚌𝚘𝚗𝚜𝚝 𝚑𝚒𝚝 = 𝚌𝚊𝚌𝚑𝚎.𝚐𝚎𝚝('𝚊𝚕𝚕_𝚙𝚛𝚘𝚍𝚞𝚌𝚝𝚜');  𝚒𝚏 (𝚑𝚒𝚝) 𝚛𝚎𝚝𝚞𝚛𝚗 𝚛𝚎𝚜.𝚓𝚜𝚘𝚗(𝚑𝚒𝚝);  𝚌𝚘𝚗𝚜𝚝 𝚙𝚛𝚘𝚍𝚞𝚌𝚝𝚜 = 𝚊𝚠𝚊𝚒𝚝 𝙿𝚛𝚘𝚍𝚞𝚌𝚝.𝚏𝚒𝚗𝚍({})   .𝚜𝚘𝚛𝚝({ 𝚙𝚛𝚒𝚌𝚎: -𝟷 }).𝚕𝚎𝚊𝚗();  𝚌𝚊𝚌𝚑𝚎.𝚜𝚎𝚝('𝚊𝚕𝚕_𝚙𝚛𝚘𝚍𝚞𝚌𝚝𝚜', 𝚙𝚛𝚘𝚍𝚞𝚌𝚝𝚜);  𝚛𝚎𝚜.𝚓𝚜𝚘𝚗(𝚙𝚛𝚘𝚍𝚞𝚌𝚝𝚜); }); 𝐓𝐡𝐞 𝐑𝐞𝐬𝐮𝐥𝐭 :  Response time dropped from ~2100ms → 60ms on repeated calls. MongoDB Atlas query profiler confirmed full index usage. Zero code refactor needed. 3 things I always do now in every MERN project: 1️⃣ Add compound indexes for frequent query patterns 2️⃣ Use .lean() on read-only queries (returns plain JS objects, not Mongoose documents — 40% faster) 3️⃣ Cache with node-cache for data that doesn't change every second Are you profiling your MongoDB queries? Most devs never open Atlas Query Profiler until something breaks. 👇 Drop your biggest MERN bottleneck in the comments — let's debug together. #MERN #MongoDB #NodeJS #ReactJS #WebDev #BackendDevelopment #JavaScript #FullStackDeveloper #Programming #100DaysOfCode

Why PostgreSQL Is a Go-To Database (Even for Frontend Engineers) When we discuss frontend development, databases often seem far away. But in real production systems, your frontend experience is directly shaped by the database choices behind the scenes. One database that consistently shows up in modern stacks is PostgreSQL. Here’s why 1. Data Consistency = Better UI Experience PostgreSQL is ACID compliant, which means: No half-saved forms No broken dashboards No inconsistent data states For frontend engineers, this translates to: Predictable API responses Fewer edge-case UI bugs Cleaner state management in React / Angular 2. Powerful Queries = Faster Screens PostgreSQL supports: Complex joins Aggregations Window functions Full-text search Instead of doing heavy data processing on the frontend: APIs return ready-to-render data Less JavaScript logic Faster page loads Result: Simpler frontend code + better performance 3. Security That Frontend Apps Rely On PostgreSQL offers: Role-based access control Row-level security Strong encryption support This helps backend teams expose safe APIs, so frontend apps: Don’t leak sensitive data Can safely implement role-based UI (admin / user / viewer) 4. Scales Well with Modern Frontend Apps Whether it’s: Infinite scroll Analytics dashboards Real-time notifications High-traffic user apps PostgreSQL scales with: Indexing Partitioning Read replicas Your frontend won’t suddenly “feel slow” as users grow. 5. Works Perfectly with Modern Frontend Stacks PostgreSQL fits naturally with: React / Angular / Vue Node.js, Java, .NET APIs GraphQL & REST ORMs like Prisma, Sequelize, TypeORM This makes it a default choice in MNCs and product-based companies. Frontend Takeaway Even if you don’t write SQL daily: Understanding PostgreSQL helps you design better UI flows You can ask smarter questions in system design interviews You stand out as a frontend engineer with backend awareness A great frontend isn’t just about pixels, it’s about reliable data. #FrontendEngineering #PostgreSQL #WebDevelopment #FullStack #ReactJS

🚀 Day 36 of My MERN Stack Journey – JWT Authentication Practice Backend ✔ Database ✔ JWT ✔ Cookies ✔ Today I practiced JWT (JSON Web Token) based authentication to clearly understand how modern web applications manage secure user login without storing sessions on the server. This was a personal practice & revision project focused on strengthening my understanding of stateless authentication using JWT. 📌 What I Practiced I created a simple authentication system where users can: ✔ Sign up and create an account ✔ Log in using contact number and password ✔ Receive a JWT token after login ✔ Store that token in cookies ✔ Access a protected profile route after token verification This helped me understand how JWT helps identify users without storing session data on the server. ⚙️ Tech Stack ✔ Node.js ✔ Express.js ✔ MongoDB ✔ Mongoose ✔ EJS ✔ Cookie Parser ✔ JSON Web Token (JWT) 🧠 Concepts I Focused On ✅ JWT Token Generation After a successful login, the server generates a signed token containing the user ID. encryptedToken = jwt.sign({ user: user._id }, "Zeroid@12321"); 📌 Concept: Creating a secure authentication token ✅ Storing JWT in Cookies The generated token is stored in a browser cookie so the server can read it on future requests. res.cookie("token", encryptedToken, { httpOnly: true, maxAge: 1000 * 60 * 60 * 24, }); 📌 Concept: Maintaining login state on the client ✅ JWT Verification When accessing protected routes like /profile, the server: 1️⃣ Reads the cookie 2️⃣ Verifies the JWT token 3️⃣ Extracts the user ID 4️⃣ Fetches the user from MongoDB decryptedToken = jwt.verify(token, "Zeroid@12321"); 📌 Concept: Stateless authentication 📝 Key Learnings from This Practice 🔹 How JWT tokens store encrypted user identity 🔹 Difference between Sessions vs JWT authentication 🔹 How cookies carry authentication tokens 🔹 How protected routes validate user identity 🔹 Why JWT is widely used in modern APIs and MERN apps 🎯 Growth Reflection Over the last few practice projects I explored three authentication systems: ✔ Cookie-based authentication ✔ Session-based authentication ✔ JWT-based authentication These revision exercises helped me deeply understand how authentication works internally in backend systems. Now I feel much more confident about building secure login systems in MERN applications. 🚀 Practice Code GitHub Repository: https://lnkd.in/dpi_VfSH #MERNStack #NodeJS #ExpressJS #MongoDB #JWT #Authentication #BackendDevelopment #JavaScript #WebDevelopment #LearningInPublic

Mongoose vs Prisma — What Should Node.js Developers Choose? One common question many developers ask when starting with backend development is: “Should I use Mongoose or Prisma?” Both tools help interact with databases in Node.js applications, but they serve different purposes depending on the database and architecture you choose. Here’s a simple comparison 👇 ⚡ Mongoose • ODM (Object Data Modeling) library designed specifically for MongoDB • Flexible schema structure for document-based data • Widely used in MERN stack applications • Uses native MongoDB-style queries Typical stack: MongoDB + Express + React + Node.js ⚡ Prisma • Modern ORM for Node.js and TypeScript • Supports multiple databases including PostgreSQL, MySQL, SQLite, and MongoDB • Provides auto-generated type-safe queries • Known for its excellent developer experience and productivity Common modern stack: Next.js + Prisma + PostgreSQL 💡 My Perspective If you're building a traditional MERN stack application, Mongoose remains a reliable and widely adopted choice. However, for modern SaaS platforms and scalable backend systems, many teams today prefer: 👉 Prisma + PostgreSQL due to type safety, scalability, and improved developer tooling. 📊 Industry Trend Many modern tech stacks are evolving toward: Next.js + PostgreSQL + Prisma + AI APIs to build scalable, maintainable, and AI-powered applications. 👨💻 What’s your preference as a developer? Do you prefer working with Mongoose or Prisma for backend development? Share your thoughts in the comments 👇 #NodeJS #BackendDevelopment #WebDevelopment #Prisma #MongoDB #SoftwareEngineering #Developers #Tech #Programming

🔎 How to Connect MongoDB in a Next.js Application using Mongoose❓ Every modern web application needs a database to store and manage data. For example: • Users • Blog posts • Comments • Application data When working with Next.js, one common approach is connecting MongoDB using Mongoose. I shared a simple implementation that explains how to set up a MongoDB database connection in Next.js and structure it so the connection can be reused across the application. 💡 Important things to consider when connecting MongoDB in Next.js: When building a database connection, a few good practices help keep the application stable and efficient. ✔ Store the database URI using environment variables ✔ Create a separate database connection file ✔ Use connection caching to avoid creating multiple database connections ✔ Define global TypeScript types when using TypeScript One important detail is that Next.js reloads the server multiple times during development. Without connection caching, the application can open many database connections, which may slow down the app or cause errors. Using a cached connection approach ensures that the same database connection is reused. 🛠 Technologies used • Next.js • MongoDB • Mongoose • TypeScript 📚 I wrote a step by step article with code examples explaining the complete setup. You can read it here: 👉 https://lnkd.in/drcjY4Gs 🤗 I enjoy sharing practical implementations while working with modern web technologies. #Nextjs #MongoDB #Mongoose #WebDevelopment #JavaScript #ReactJS #TypeScript #FullStackDevelopment #SoftwareDevelopment #FrontendDeveloper

𝗗𝗮𝘆 𝟳/𝟮𝟭: 𝗘𝘅𝗽𝗿𝗲𝘀𝘀.𝗷𝘀 - 𝗧𝗵𝗲 𝗚𝗮𝘁𝗲𝘄𝗮𝘆 𝘁𝗼 𝗦𝗰𝗮𝗹𝗮𝗯𝗹𝗲 𝗔𝗣𝗜𝘀 🛣️ One week down in my #21DaysOfMERN challenge! Today, we are layering Express.js on top of Node. It’s the "E" in MERN, and it’s what turns a raw Node server into a powerful, organized API machine. If Node.js is the engine, Express is the dashboard and the GPS. It tells the server exactly where to go when a user makes a request. 🌟 𝗧𝗵𝗲 𝗜𝗻𝗱𝘂𝘀𝘁𝗿𝗶𝗮𝗹 𝗨𝘀𝗲: 𝗥𝗼𝘂𝘁𝗶𝗻𝗴 & 𝗠𝗶𝗱𝗱𝗹𝗲𝘄𝗮𝗿𝗲 In a production environment (think Spotify or Twitter), a server handles millions of requests. Express excels because of its Middleware architecture. > 𝗥𝗼𝘂𝘁𝗶𝗻𝗴: Directing a user to /profile vs /login without writing messy, hundred-line if-else statements. > 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆 & 𝗟𝗼𝗴𝗶𝗰: Before a request even hits the database, Express middleware can check if a user is logged in, log the request for analytics, or compress the data for faster delivery. 🛠️𝗧𝗵𝗲 𝗜𝗺𝗽𝗹𝗲𝗺𝗲𝗻𝘁𝗮𝘁𝗶𝗼𝗻 𝗟𝗼𝗴𝗶𝗰: 𝗧𝗵𝗲 "𝗥𝗲𝗾𝘂𝗲𝘀𝘁-𝗥𝗲𝘀𝗽𝗼𝗻𝘀𝗲" 𝗖𝘆𝗰𝗹𝗲 Every Express app follows a simple but strict flow: 𝟭. 𝗧𝗵𝗲 𝗥𝗲𝗾𝘂𝗲𝘀𝘁 (𝗿𝗲𝗾): What the user sends (data, headers, tokens). 𝟮. 𝗠𝗶𝗱𝗱𝗹𝗲𝘄𝗮𝗿𝗲:A series of "checkpoints" the request passes through (Auth, Validation, Parsing). 𝟯. 𝗧𝗵𝗲 𝗥𝗲𝘀𝗽𝗼𝗻𝘀𝗲 (𝗿𝗲𝘀): What the server sends back (JSON data, status codes like 200 or 404). 💡𝗠𝘆 𝗜𝗺𝗽𝗹𝗲𝗺𝗲𝗻𝘁𝗮𝘁𝗶𝗼𝗻 𝗦𝘁𝗿𝗮𝘁𝗲𝗴𝘆 (𝗧𝗵𝗲 𝗦𝗵𝗲𝗿𝘆𝗶𝗮𝗻𝘀 𝗔𝗽𝗽𝗿𝗼𝗮𝗰𝗵) 𝗠𝗼𝗱𝘂𝗹𝗮𝗿 𝗥𝗼𝘂𝘁𝗶𝗻𝗴: I don’t cram everything into one file. I use express.Router() to keep my code clean and "Pluggable." 𝗚𝗹𝗼𝗯𝗮𝗹 𝗘𝗿𝗿𝗼𝗿 𝗠𝗶𝗱𝗱𝗹𝗲𝘄𝗮𝗿𝗲: I implement a centralized error-handling middleware. This ensures that if something breaks, the user gets a clean JSON error message instead of the server crashing. 𝗥𝗘𝗦𝗧𝗳𝘂𝗹 𝗣𝗿𝗶𝗻𝗰𝗶𝗽𝗹𝗲𝘀: I’m focusing on building "clean" URLs. No more get-all-users-data; just a simple GET /users. Week 1 has been about the "How" and "Why." Week 2 is where we start connecting the dots! 🙌 Shoutouts & Network: Huge thanks to the Sheryians Coding School community for the support in Week 1! Harsh Vandana Sharma | Sarthak Sharma | Ankur Prajapati Do you prefer "Express" for its minimalism, or do you like more "batteries-included" frameworks like NestJS? Let’s talk! 👇 #MERNStack #21DaysOfMERN #ExpressJS #BackendEngineer #WebDevelopment #SheryiansCodingSchool #JavaScript #APIDevelopment #Middleware #SoftwareArchitecture #CodingChallenge #Week1Complete

Building a robust MERN application is often less about the code you write and more about the "silent killers" you ignore. If you’ve ever had a production build crash because of a "simple" schema change or a stray environment variable, this is for you. The Hidden Cost of "It Works on My Machine" In the MERN ecosystem (MongoDB, Express, React, Node.js), we move fast. We love the flexibility of JSON-like documents and the speed of JavaScript across the whole stack. But that flexibility is a double-edged sword. Following are three structural traps most developers fall into and how to bridge the gap: 1. The "Schemaless" MongoDB Myth Just because MongoDB doesn't force a schema doesn't mean you shouldn't have one. Relying solely on application-level validation (like Mongoose) without considering database indexing or document versioning is a recipe for technical debt. The Fix: Implement strict JavaScript interfaces that mirror your Mongoose schemas to ensure type safety from the query to the UI. 2. The State Management Overkill React developers often jump to Redux or complex Context providers for data that could be handled by simple URL params or a localized hook. The Fix: Ask yourself: "Does this state need to persist across a refresh?" If not, keep it local. If it’s server data, use something like TanStack Query to handle caching and synchronization automatically. 3. The 'Heavy' Node Backend Node.js is incredible for I/O, but it’s single-threaded. If you’re performing heavy data processing or image manipulation directly in your Express routes, you’re blocking the event loop for every other user. The Fix: Offload CPU-intensive tasks to Worker Threads or a dedicated microservice. #MERNStack #MongoDB #NodeJS ##WorkerThread #MicroServices #ReduxToolkit #ReactQuery #SoftwareEngineer Haroon Rasheed

🚀 Backend Practice: Building REST APIs with Node.js & MongoDB I’ve been working on improving my backend development skills, and in this assignment I focused on building a small backend system using Node.js, Express.js, and MongoDB. The goal was to practice working with NoSQL databases, organizing backend code, and implementing clean API structures. 💻 What I implemented in this project: • Creating an explicit MongoDB collection with schema validation rules • Building multiple RESTful API endpoints using Express.js • Implementing database operations like create, read, update, and query filtering • Organizing the backend using a modular architecture (modules → controller → service) • Handling validation and errors properly 📂 Project Structure: The project is organized to keep the backend scalable and maintainable: src - db → database connection, models, and exports - modules   - user → controller & service   - note → controller & service - index.js → application entry point This structure helps separate responsibilities and makes the code easier to maintain and extend. 🛠 Technologies used: Node.js Express.js MongoDB Every small project like this helps me understand better how real backend systems are designed and how APIs communicate with databases. 📌 GitHub Repository: https://lnkd.in/d2jBsiCD Always open to feedback and suggestions from the developer community 🙌 #BackendDeveloper #NodeJS #MongoDB #ExpressJS #RESTAPI #SoftwareEngineering #LearningInPublic

 The domain for our problem essentially consisted of four entities: orders, contractors, users and companies (condominiums). However, the main process is order processing, so the relations between entities are not so important and can be implemented by embedding a contractor and a user into an order. In this case, the use of relational databases like MySQL or PostgreSQL become optional and NoSQL databases are already competitive and more adequate for the problem. My choice fell on Mongo DB. Late, during the implementation of the project, an analogue of the relational join construct arose only once, and then only for report generation. This means that the use of NoSQL database was completely suitable for our task. There was no problem choosing a main back-end tool. Given my existing work experience, the primary and only candidate was a Java-based Spring framework (more precisely Spring Boot). In additional to classic web processing modules (spring-boot-web and spring-boot-rest) and ready-made and detailed interfaces for work with persistent data (e.g., spring-boot-mongo, mongotemplate), Spring framework contains a huge number of various modules implementing all sorts of useful functionality. In particular, there is spring-boot-security, which allowed us to organize work based on roles, as well as spring-boot-mail, which allowed for e-mail sending. The only tool not from the Spring ecosystem is Amazon AWS SDK SNS module used for sending SMS messages. As for the front-end, the author was very tempted to create SPA application based on React or Vue. However, a superficial familiarity with these frameworks (which meant that during the development of the application it would be necessary to master them more deeply) and reluctance to move business logic to the client side led to the abandonment of this idea. I also didn’t want to upload large JS libraries onto the web browser. For this reason, J-query and Bootstrap were out too. The bare Java-script remained. To somehow compensate the difficulties that are characteristic of this approach, I added Thymeleaf template engine on the server side. The Thymeleaf fragment technique allowed us to work with components. Besides, the use of REST API made it possible to perfectly replace what should have been a join operator for relational databases. Thus the work was carried out within the classical pattern MVC. In addition, there was a requirement of possibility to work with application from smartphones. To avoid developing separate iOS and Android apps (which would have required far more resources that I had) we decided to limit ourselves with a classic web app. However, all web pages had to be optimized for phones too. to be continued