Durvesh Gaikwad’s Post

🚀 Backend Upgrade in Progress! Here’s what I improved 👇 ✅ Added structured middleware — CORS with env-based origin, body size limits, cookie parsing, and static assets ✅ Deferred server startup until MongoDB connects to ensure reliability ✅ Introduced utility helpers like ApiResponse, ApiError, and asyncHandler for consistent error and response patterns Key Learnings: 🔹 Secure and environment-driven configuration 🔹 Predictable request lifecycle 🔹 Cleaner, more maintainable controller logic 🔹 Error Handling 💡 Takeaway for others: Centralize middleware early, wrap async handlers to avoid repetitive try/catch blocks, and standardize responses — it’ll make your backend far easier to debug and scale! Check out all my Backend Practices here 👇 🔗 GitHub Repo: https://lnkd.in/dAa5nBid #NodeJS #MongoDB #Backend #Mongoose #WebDev #Learning #FullStack

🚀 Professional Backend Setup — Authentication Upgrade! Today, I added a complete auth layer to my production-minded Node.js + MongoDB backend 👇 ✅ Built a User model with bcrypt password hashing and JWT (access + refresh tokens) ✅ Used env-based secrets and expiries for secure, flexible configuration ✅ Embedded auth logic inside the model to keep controllers clean and maintainable Key takeaway: Standardizing response/error patterns early and securing configs through environment variables makes scaling (token rotation, observability, rate limiting) much smoother 💡 Check out all my Backend Practices here 👇 🔗 GitHub Repo: https://lnkd.in/dAa5nBid #NodeJS #MongoDB #Backend #Mongoose #WebDev #Auth #Learning #FullStack #CleanCode

🚀 Developed a full-stack web app for secure file uploads using React, FastAPI, PostgreSQL, and AWS S3 Over the past few days, I worked on a complete end-to-end full-stack project that integrates modern web technologies, cloud services, and production-level deployment concepts. Here’s what I built 👇 🧩 Tech Stack 🎨 Frontend: React + Tailwind CSS ⚙️ Backend: FastAPI (Python) 🗄️ Database: PostgreSQL (AWS RDS) ☁️ Storage: AWS S3 (Presigned uploads) 🌐 Deployment: EC2 + NGINX + a background Linux service for automatic startup and reliability ⚡ Features ✅ Secure user signup/login with JWT authentication ✅ Password hashing and duplicate email validation ✅ Auth-protected APIs for user info and uploads ✅ Direct file uploads from the browser to S3 using presigned URLs (no backend file storage) ✅ Clean, minimal React dashboard with login, logout, and upload flow ✅ Fully deployed and tested on AWS infrastructure 🧠 What I Learned ·       Designing a secure authentication system using JWT in FastAPI ·       How presigned S3 URLs enable secure, direct file uploads without exposing AWS credentials ·       Configuring NGINX to serve React and proxy API requests to FastAPI ·       Running backend processes as persistent services on Linux for uptime and auto-restarts ·       Managing CORS, AWS permissions, and environment variables in production environments It was a great experience connecting frontend, backend, and cloud infrastructure into a single production system. #FastAPI #React #AWS #FullStackDevelopment #Python #PostgreSQL #S3 #WebDevelopment #CloudComputing

🚀 DevTinder — A Small Realisation That Improved My Backend Thinking While working on my DevTinder project, I noticed something interesting in my backend setup. At first, I used this pattern because “everyone does it.” But then I asked myself: Why do we connect the database first… and then start the backend server? And the answer actually improved the architecture of my project. 🔍 The simple logic: Your backend is only “alive” when it can actually talk to the database. In DevTinder, almost every feature — ✔️ Signup ✔️ Login ✔️ Profile update ✔️ Match requests ✔️ Chats — depends completely on MongoDB. So if my server starts before the DB is connected, the entire user flow breaks. It’s like opening DevTinder for users when the database is still sleeping. 😄 💡 What I learned: First ensure MongoDB is connected successfully Then start the server This guarantees that every route works from the very first request And it makes the whole application more stable and reliable This small understanding made me more confident in how I structure real-world backend systems. #NodeJS #BackendDevelopment #WebDevelopment #MongoDB #ExpressJS #SoftwareEngineering #Learnings #DevTinder #CodingJourney #FullStackDeveloper

I needed delayed jobs in a recent NextJS/Prisma/Vercel project. Most playbooks say: “Add Redis + BullMQ” or “spin up Kafka.” Instead, I used Postgres + Prisma — the database we already had. Not because it’s clever — but because it was enough. And it will be enough until my client is doing hundreds of millions in revenue. A simple jobs table, a run_at timestamp, and a scheduled check. No new services to pay for. No new permissions or ops overhead. No extra containers. Just making the most of the system that was already there. The lesson: Simplicity isn’t a compromise — it’s a strategy, especially when you (or your client) are bootstrapping. Complexity has a cognitive cost, and every new tool is a future obligation. Keep it boring until boring breaks. Don’t go out and buy a reciprocating saw to cut your baguette.

Continuing my backend journey with Node.js + Express + MongoDB, I’ve implemented major logic improvements around connection handling and pagination. New Features Implemented: ✅ Separate ConnectionRequest Schema with statuses: interested, ignored, accepted, rejected ✅ Logic for preventing duplicate or reversed requests ✅ APIs: • GET /user/received – fetch received connection requests • GET /user/connections – list accepted users • GET /user/feed – fetch suggested users ✅ Filter logic: • Excludes already connected, rejected, or self-users ✅ Added Pagination using skip and limit for performance and scalability This phase helped me dive deep into query optimization, relationship handling, and corner case management — crucial for building production-ready APIs. Next step → Real-time updates with Socket.io 🔥 #NodeJS #ExpressJS #MongoDB #BackendDevelopment #MERNStack #WebDevelopment

Week 1 of 𝗗𝗼𝗰𝗸𝗲𝗿 — 3 full-stack apps live with 𝗗𝗼𝗰𝗸𝗲𝗿 𝗖𝗼𝗺𝗽𝗼𝘀𝗲! 🐳 𝟯-𝗧𝗶𝗲𝗿 𝗔𝗽𝗽 (Nginx + Flask + Postgres) → Reverse proxy, persistent DB, service discovery 🔗 https://lnkd.in/dbKdCi4K 𝗧𝗼𝗱𝗼 𝗔𝗽𝗽 (Node.js + MySQL + Nginx) → CRUD, env vars, dependency health 🔗 https://lnkd.in/duWAdvb3 𝗨𝘀𝗲𝗿 𝗣𝗿𝗼𝗳𝗶𝗹𝗲 (Node.js + MongoDB + Mongo Express) → API + DB UI, volume persistence 🔗 https://lnkd.in/dCa32sba Loving 𝗱𝗼𝗰𝗸𝗲𝗿-𝗰𝗼𝗺𝗽𝗼𝘀𝗲 𝘂𝗽 and log debugging! 𝗡𝗲𝘅𝘁 𝘄𝗲𝗲𝗸: Multi-stage builds + Nginx config for multi-site hosting #Docker #DevOps #LearningInPublic

I finally released something I’ve been relying on for years in production… Every time I built a scalable Node.js app using cluster or multiple worker processes, I ran into the same nightmare: “How do I safely share and update JSON state across processes… without race conditions, corrupted files, or hacky workarounds?” Over time, I built my own internal tool to solve it. It worked so well that I used it in every project since. And now… I finally had the time to polish it and publish it. 🎉 ✅ Introducing djs-kt — Dynamic JSON Manager (with Redis + distributed locks) A lightweight library that lets you treat shared JSON like a safe, async data structure — even across clustered or multi-host environments. Why it exists: Because managing shared state across processes is HARD, and no existing solution was clean or safe enough. What it handles for you: ✅ In-memory, file-based, or Redis-backed JSON state ✅ Fully cluster-safe — workers send operations to the primary ✅ Distributed locks via Redis for multi-host setups ✅ Simple async API: get, set, push, batch, etc. ✅ Written in TypeScript, with full typings ✅ Tiny, modular, no heavy framework It feels like working with a normal JS object… …but under the hood it does IPC, locking, and persistence the right way. Honestly, this library saved me countless hours and prevented so many concurrency bugs. I’m excited to finally share it with the community. 🔗 GitHub: https://lnkd.in/dZhekQGE 📦 npm: npm install djs-kt If you’ve ever struggled with shared state in Node.js, I’d love to hear your feedback or ideas. Let’s make this even better together. 🙌 note this is very useful in presence state tracking for example, it could be improved on by making a transaction like logic for consequetive state manipulation, like getting a counter value incrementing it and updating its value #nodejs #typescript #redis #concurrency #distributedSystems #opensource #npm #backend

🚀 Namaste Node.js Episodes 11 & 12: Servers & Databases In these episodes, I explored two of the most important backend concepts 🖥️ Servers: Can refer to both hardware (machines) and software (apps handling requests). Each app runs on a specific port (like localhost:999). Multiple servers can run on one system using different ports. 🌐 Client–Server Model: Clients send requests → servers process → respond → connection closes. WebSockets make this real-time and persistent 🔄 💾 Databases: I also learned about types like: SQL (MySQL, PostgreSQL) → Structured data, ACID compliant NoSQL (MongoDB) → Flexible JSON documents Redis → Super-fast in-memory caching Neo4j, InfluxDB, CockroachDB → For graphs, time-series & distributed systems 💡 Takeaway: Servers handle requests; databases store and organize data. Together, they form the backbone of every web application. #NodeJS #BackendDevelopment #NamasteNodeJS #JavaScript #LearningJourney #Servers #Databases

Once Docker and Nexus registry are fully configured, there’s one more critical step, and that's updating the application code so everything runs inside the containers. In our NodeJS app, you’ll find a MongoDB connection that works only when running the app locally, but when the app runs inside Docker, “localhost” doesn’t refer to our machine anymore, it refers to the container itself. That’s why we replace the line here Connection string for running the application locally (outside of Docker) let mongoUrlLocal = "mongodb://admin:password@localhost:27017"; With the updated reference Connection string for running the application inside Docker (via Docker Compose) let mongoUrlDockerCompose = mongodb://admin:password@mongodb Docker Compose creates an internal network where containers communicate using service names, not localhost. The name mongodb comes from our docker-compose file. It’s the service name assigned to MongoDB container. This ensures the NodeJS container connects to the MongoDB container whether testing locally or deploying remotely, and with Nexus handling the Docker images, this small code change ensures the app runs across all environments after pulling the image from the private registry. That single line bridges everything. Nexus hosts our Docker images, Docker Compose orchestrates our containers MongoDB stores our app data, and NodeJS communicates between them. Without this connection change, the app would fail to reach the database, and this is why small configuration updates can make or break a containerized architecture. #Docker #Architecture #TWNDevOps #Containers #Automation