🚀 Why I use BullMQ in my NestJS backend and why you should too Most developers send emails directly inside their API route. It works, But your users are sitting there waiting for your SMTP server to respond before they get a reply. That's a bad experience. And in production, it's a real problem. ❌ 🤔 What is BullMQ? BullMQ is a job queue library for Node.js backed by Redis. Instead of doing heavy or slow tasks like sending emails synchronously inside your request lifecycle, you push them into a queue. A background worker picks them up and handles them independently so your API responds instantly. ⚡ ✅ When should you use it? 📧 Sending emails or SMS after signup/login 🖼️ Processing uploaded files or images 📄 Generating reports or PDFs ⏳ Any task that doesn't need to block the HTTP response 🎯 What I demonstrated: I built a signup endpoint with NestJS. In the first version, the API waits for the email to be sent before responding response time: ❌ 6.48 seconds. In the second version, the email job is pushed to a BullMQ queue and the API responds immediately response time: ✅ 947ms. That's an 🔥 85% reduction in response time. The difference speaks for itself. 💡 If you're building production APIs, async job queuing is not optional. It's a standard. 🛠️ Stack used: NestJS · BullMQ · Redis · Nodemailer · MongoDB #nodejs #nestjs #bullmq #redis #backend #webdevelopment #softwaredevelopment

🚀 I just shipped a full-stack real-time chat application and the debugging journey taught me more than building it did. Remember I said I will be adding more features. Yes, I have added more! Here's what I built: ✅ Public group chat with live presence ✅ Private one-on-one messaging between users ✅ JWT authentication with session persistence ✅ Typing indicators and message history ✅ Rate limiting to prevent spam The stack: NestJS + Socket.IO + PostgreSQL + Redis + vanilla JS frontend. But the part I'm most proud of isn't the features — it's the bugs I had to chase down to make private messaging actually work. Three that stood out: 🐛 Messages were saving to the DB with a null userId — because the gateway was passing user.id (a string) to a service that expected the full User object. One character fix, hours of debugging. 🐛 The recipient never received messages — because only the sender was joining the private Socket.IO room. The fix was using fetchSockets() to find the recipient's active socket and programmatically joining them to the room on the backend. 🐛 The frontend was sending a username string as recipientId instead of a UUID — so the socket lookup always returned null. Root cause: Redis was storing plain username strings in the presence set, not user objects. Fixed by adding a Redis hash map (user_id_map) to preserve the id ↔ username relationship. Real-time systems have a way of exposing every assumption you didn't know you were making. The code is on GitHub and the article is on medium— links in the comment. 👇 #NestJS #NodeJS #WebSockets #SocketIO #Redis #PostgreSQL #BackendDevelopment #SoftwareEngineering

Sick of bloated ORMs killing your serverless performance? Meet Drizzle ORM — the lightweight champion that gives you full type-safe SQL without any overhead. ~7.4KB gzipped (130x smaller than Prisma) Write queries that feel like raw SQL but with perfect TypeScript inference Blazing-fast cold starts on Vercel, Cloudflare, Neon & more No codegen headaches. Pure TS schema + Drizzle Kit for effortless migrations If you love SQL but want rock-solid type safety, this is it. #DrizzleORM #TypeScript #NextJS #NodeJS #WebDev #Serverless #Prisma #TypeSafeSQL #FullStack

Day 22 Of Web Dev Cohort at Chai Aur Code Backend with TypeScript, Drizzle & PostgreSQL ⚡ Been exploring a more structured backend setup… and it just feels right. ↪ TypeScript brings type safety and fewer runtime errors ↪ Drizzle ORM keeps database queries clean and simple ↪ PostgreSQL handles structured data like a pro ↪ Type-safe queries make debugging way easier ↪ Better foundation for scalable backend apps Before this, backend felt a bit “hope it works”... Now it feels predictable. Still learning the deeper parts… but this stack is starting to click. #BackendDevelopment #TypeScript #PostgreSQL #WebDevelopment #ChaiCode

Day 73 of #100DaysOfCode Today I implemented pagination and performance optimization in my full-stack project. Covered: • Page-based data fetching • Backend pagination with skip & limit • Improving API performance This is essential for building scalable applications #FullStackDevelopment #ReactJS #NodeJS #MongoDB #LearningInPublic

I just launched my first open-source CLI tool. 🙌 create-samrose-app lets you scaffold a full Next.js stack interactively with a single command. The idea came from a frustration I kept running into: every new project starts with the same setup marathon. ORM config, database setup, auth wiring, CI/CD... before you've written a single feature. So I built the tool I always wanted. $ npx create-samrose-app You pick: • ORM (Prisma, Drizzle, TypeORM, Mongoose) • Database (PostgreSQL, MySQL, SQLite, MongoDB) • Auth (NextAuth, Clerk, JWT) • State (Zustand, Redux, Recoil) • API (tRPC, oRPC, GraphQL, REST) • Testing + extras like Docker & GitHub Actions Everything wired together. Everything production-ready. Building this taught me a ton about CLI design, cross-stack compatibility, and open-source documentation. If you try it, let me know what you think — feedback and contributions are very welcome. And if it saves you even 30 minutes, a ⭐ on GitHub would make my day! 🌐 Docs: https://lnkd.in/gqx_EJgE 📦 npm: https://lnkd.in/g93iKfMg 💻 GitHub: https://lnkd.in/gBiB9yMh #OpenSource #NextJS #CLI #BuildInPublic #DevTools #Package

NAPI-RS has transformed my approach to handling databases in personal projects. Previously, I was juggling MongoDB, MySQL, and Redis, managing three separate clients with distinct patterns, which became quite cumbersome. With NAPI-RS, I can write Rust and expose it to Node.js as a native binary. By simply adding one #[napi] macro to my async function, it seamlessly becomes a typed JavaScript Promise. TypeScript types are auto-generated, eliminating the need for FFI boilerplate and version management issues. I encapsulated each database within its own small Rust module, compiling them into a single .node binary. Now, every project can simply do: const { mongo, mysql, redis } = require('./db-core') This results in one consistent API and a centralized location for updating connection logic, ensuring uniformity across projects. The Rust side efficiently manages performance-critical aspects such as pooling, retries, and concurrent I/O, while the JavaScript side simply awaits the results. It's a straightforward concept that proves genuinely useful in practice. Full write-up on Medium — link in the comments. #Rust #NAPI #NodeJS #BackendDev #SideProject #OpenSource

Excited to share something I recently built as part of an interview assignment — a full-stack Goal Tracking application! 🎯 The project (https://lnkd.in/g4qQdDPp) is built on a Node.js + Express backend, MongoDB as the database, and a React frontend — all containerized and orchestrated using Docker. Here's what went into it: 🔐 User Authentication — JWT-based auth with bcrypt password hashing. Stateless sessions that keep the architecture clean and scalable from day one. 📋 Goal Management API — Full CRUD operations structured around RESTful principles, with a consistent response contract across every endpoint. 🏥 Health Monitoring — A dedicated /health endpoint to verify server and database status in real time. Something I now treat as a non-negotiable in any production-ready service. 🌐 CORS Configuration — Properly configured Cross-Origin Resource Sharing so the React frontend and Node backend communicate securely across different origins. 📦 Docker & Docker Compose — Wrote separate Dockerfiles for both the Node.js backend and the React frontend, then orchestrated all three services — frontend, backend, and MongoDB — using a single docker-compose.yml. One command to spin up the entire stack. That's the kind of developer experience that matters in real teams. 📄 API Documentation — Documented all endpoints using Postman, making the API immediately explorable and shareable with any team member without reading a single line of source code. 🧱 Industry-Standard Practices followed throughout: — MVC-inspired structure for clear separation of concerns — Environment-based configuration using dotenv — Centralized error handling middleware — Input validation at the API layer — Mongoose schemas with proper data modeling Building this end-to-end — from database design to containerized deployment — was a great exercise in thinking about systems holistically. Not just writing code that works, but code that scales, is maintainable, and is easy for any developer to pick up and run. Always learning. Always building. 🚀 #FullStack #NodeJS #React #MongoDB #Docker #DockerCompose #WebDevelopment #BackendDevelopment #SoftwareEngineering #OpenToWork

A client called me at 10am. "The dashboard is freezing. Users are leaving." I'd built the thing 3 months earlier. Proud of it, honestly. I opened the queries. Raw .find({}) on collections with 50k+ documents. No indexes. No projection. Just pulling everything and filtering in JavaScript like some kind of monster. That was me. I wrote that. 48 hours later — compound indexes on the hot fields, $match early in every pipeline, .lean() on read-heavy routes, .select() stripping fields nobody needed. Query time: 1.8 seconds → 280ms. 40% performance gain. Zero infrastructure changes. The database wasn't slow. I just didn't know how to ask it things properly. Before you pay for more RAM or spin up another replica — read your queries. Actually read them. Something dumb is probably in there, and it was probably you who wrote it. (It was definitely me.) #MERN #MongoDB #FullStackDeveloper #NodeJS #BackendDevelopment

AuthN and AuthZ project update 🔐📈 I approached this project through a structured roadmap. I broke the complexity down into strategic milestones to go from zero to a fully functional Auth system. Project Link: https://lnkd.in/gfh4gDgV Milestone 1 -- Infrastructure 👷🏽♂️ Goal was to get Postgres and Redis running locally. Establish DB connection. and Run migrations. Files I created > docker-compose.yml: Runs Postgres + Redis as containers. Single command startup. > .env | Local environment variables. Git-ignored. > src/db/postgres.js | Creates and exports the pg connection pool. > src/db/redis.js | Creates and exports the ioredis client. > src/app.js Express app setup. > server.js Entry point. Imports app, starts server on PORT. > env.js | Load dotenv. Read each variable. If any required variable is missing or empty, throw an error immediately with a clear message. > Migrations files path(src/db) users table schema, refresh_tokens table schema, audit_logs table schema, Performance indexes on all lookup columns. > src/db/migrate.js | Read all .sql files from the migrations folder in order. > Dependencies: express pg, ioredis, bcrypt, jsonwebtoken, dotenv, uuid pino, pino-http, pino-pretty > Dev Dependencies: Nodemon, jest, supertest Verification > docker compose up -d > node src/db/migrate.js | should print each migration name with no errors > node server.js #Authentication #BackendEngineering #Docker #NodeJS #Express #Postgres #Redis