DEV Community: Dorcas Nyamekye Quaye

Stop Copying ObjectIDs: Use Slugify in Your Node.js API (E-Commerce)

Dorcas Nyamekye Quaye — Thu, 04 Sep 2025 17:54:24 +0000

I used to spend extra time copying database ObjectIDs when testing my endpoints. I'd be creating categories, products, and all kinds of CRUD operations, only to dig through the database for IDs every time.

Then I discovered slugify, a small Node.js package that makes URLs readable, SEO-friendly, and much easier to test. Suddenly, instead of typing /categories/6489f3a2b6c1f7a12345, I could just type /categories/mens-clothing and keep moving.

What is Slugify?

Slugify is a simple Node.js package that converts strings into URL-friendly “slugs.” It’s user-friendly, lowercase, hyphenates spaces, and removes unsafe characters, making URLs clean and readable.

For example:

"Men's Clothing" → "mens-clothing"
"Café & Restaurant!" → "cafe-restaurant"

This is especially useful for categories, products, or any resource you want to make readable in a URL.

Don’t Confuse Slugify with Basic String Methods

It’s important not to confuse slugify with just using basic string methods like trim() or toLowerCase().

trim() only removes spaces at the start or end of a string:

"  Men's Clothing  ".trim(); // "Men's Clothing"

toLowerCase() only converts letters to lowercase, but leaves spaces and special characters untouched:

"Men's Clothing".toLowerCase(); // "men's clothing"

If you combine them:

"  Men's Clothing  ".trim().toLowerCase(); // "men's clothing"

You still end up with spaces and special characters, which isn’t URL-friendly.

Slugify, on the other hand, does all of this in one step:

Converts to lowercase
Replaces spaces with hyphens
Removes or replaces unsafe characters

import slugify from 'slugify';

slugify("  Men's Clothing  ", { lower: true }); 
// "mens-clothing"

Now the string is clean, readable, and ready for a URL.

Why Use Slugify in E-commerce?

SEO-Friendly URLs – Search engines prefer meaningful, readable URLs.
Better UX – Users can read and remember URLs easily.
Simpler Routing – Fetch resources by slug instead of ID.
Easier Testing & Debugging – From a developer perspective, using slugs saves you from copying database IDs every time you test an endpoint. You can type a readable slug like mens-clothing and test your routes faster.

For me, this made testing category endpoints much simpler. Every category I create now has a slug, and I can remember or type it easily without digging into the database.

How I Implemented It in Node.js

First, install the package:

npm install slugify

Then, use it when creating a new category:

import slugify from 'slugify';

const categoryName = "Men's Clothing";

//convert to slug
const categorySlug = slugify(categoryName, { lower: true });

//save in DB
const newCategory = await Category.create({ 
  name: categoryName, 
  slug: categorySlug 
});

Now, instead of /categories/6489f3a2b6c1f7a12345, your URL looks like:

/categories/mens-clothing

Some Use Cases of Slugify:

Takeaway

Slugify isn’t just about SEO or user-friendly URLs—it’s also a huge help for backend developers. It makes testing, debugging, and working with CRUD endpoints much simpler.

If you’re building categories, products, or other resources for a web app, I highly recommend giving it a try. Clean URLs, easier testing, happy developers, happy users!

My First Steps with Socket.IO: Real-Time Updates Made Simple

Dorcas Nyamekye Quaye — Mon, 25 Aug 2025 11:55:15 +0000

Until now, I’ve mostly worked with RESTful APIs where requests and responses follow a one-way flow (using HTTP). Basically, the client asks for something → the server replies → and that’s it.

But this time around, I had to bring in Socket.IO. And I quickly asked myself: how different is this from HTTP?

Well, HTTP is just request and response. The client makes a call, and the server gives a fixed reply. If you want new updates, you have to ask again and again.

With Socket.IO, it feels different — it gives you live updates without you always needing to call the server.

🌐 A Simple Analogy

Think of HTTP as writing letters ✉️.
You send one, wait for a reply, then send another.

Now, think of WebSocket/Socket.IO as a phone call 📞.
Once connected, both sides can talk freely without hanging up each time.

That simple picture helped me understand it better.

👩‍💻 How I Set It Up

So this is how I set it up the first time I tried Socket.IO 👇

1. On the Node.js backend:
Normally, I’d just do:

app.listen(port, () => {
      console.log(`Server listening on $PORT`);
    });

But this time, since I wanted to add Socket.IO, I had to wrap my app with an HTTP server and then use server.listen instead. I also set it up to send live updates (in this case, “new posts”) to the client:

import express from "express";
import { createServer } from "http";
import { Server } from "socket.io";

const app = express();
const server = createServer(app);
const io = new Server(server, { cors: { origin: "*" } });

io.on("connection", (socket) => {
  console.log("Client connected");

  // Send a "new post" update every 5 seconds
  setInterval(() => {
    socket.emit("newPost", {
      title: "📢 New update just arrived!",
      content: "This is a live post pushed from the server",
    });
  }, 5000);

  socket.on("disconnect", () => {
    console.log("Client disconnected");
  });
});

server.listen(port, () => {
      console.log(`Server listening on $PORT`);
    });

2. On the React client:

Then, I went to the client side and connected it like this:

import io from "socket.io-client";

const socket = io("http://localhost:6002");

// Listen for live post updates
socket.on("newPost", (data) => {
  console.log("Live update:", data.title, "-", data.content);
});

✨ Wrapping Up

So that’s how I first set it up — changing my app.listen to server.listen, and then configuring both sides so the server could push live updates straight to the client.

This was my very first introduction to Socket.IO, and it already made sense how powerful it can be for things like:

Live chat
Notifications
Collaborative apps

I know there’s still much more to learn, but this was a great starting point. If you’ve worked with Socket.IO before and have tips or resources, I’d love to hear them 😁

How .aggregate() Powered Our Learner & Income Analytics in MongoDB

Dorcas Nyamekye Quaye — Sat, 09 Aug 2025 22:33:16 +0000

This week, I worked on something exciting: reports routes for our backend. This is the part of the system that helps admins see important data at a glance. My job was to build endpoints that could transform raw learner and payment data into meaningful insights, including:

A list of all learners
The number of learners per track
The total income
The income per track

In short, I wasn’t just fetching data anymore. I was shaping it into something an admin could actually use to make decisions.

Pretty straightforward on paper, but here’s where the twist came in. I had to use MongoDB’s .aggregate() for the first time.

Before this, I had been living in the world of .find() and .findOne(). They were my comfort zone; very simple, direct, and predictable. But for this task, I needed more power: grouping data, filtering it, reshaping fields, and running calculations all in one go. That’s where .aggregate() stepped in.

One of my tasks was to get the number of learners in each track only if they had paid. With .aggregate(), I learned I could:

Filter with $match
Group with $group
Count or sum fields using $sum
Reshape or limit fields with $project

Here’s a little snippet from what I wrote:

const result = await learnerModel.aggregate([
  { $match: { status: 'paid' } },
  {
    $group: {
      _id: "$track",
      count: { $sum: 1 }
    }
  },
  {
    $project: {
      track: "$_id",
      count: 1,
      _id: 0
    }
  }
]);

In this example, $project let me clean up the output by renaming _id to track and hiding unnecessary fields.

Seeing the data come out exactly as I needed — filtered, grouped, and neatly shaped — felt so satisfying. It was like discovering that MongoDB had been quietly hiding a mini data-analytics tool inside it all along.

This experience was more than just adding new routes. I learned a new way of thinking about database queries, and I’m already imagining all the other problems .aggregate() could help me solve.

My First Dive into Real Payments Integration (with Paystack and Webhooks)

Dorcas Nyamekye Quaye — Sat, 02 Aug 2025 12:04:23 +0000

This week, I did something that felt both exciting and intimidating. I integrated a payment gateway into one of my backend APIs for the very first time, even if it was just in test mode. 🙈💳

Now, I’ve created APIs before, like user authentication, CRUD operations, and more. But this time? I wanted my API to handle actual payments and that felt like stepping into a new territory.

☺️ Why I Took This On

I’ve been working on an API where learners can register for a course track. I already had the backend logic for signing up, viewing courses, and assigning users to tracks. But I had to take it a step further:

What if learners could also pay and automatically get an invoice confirmation?

So I jumped into payment processing for the first time with no real business setup, just the test mode that Paystack provides to simulate real-life transactions.

🔄 Here’s What I Built

Invoice Generation: When a learner is about to pay for a course, the backend creates an invoice showing the amount, due date, Paystack payment link , and learner info.
Verify Payment Endpoint: I created a /verify-payment endpoint to verify if a transaction is real. This uses the Paystack verification API to confirm that the payment went through. This helped me ensure the payment wasn’t faked or interrupted.
Webhook Integration: This was the exciting part. I set up a /webhook route to receive notifications from Paystack.

🤔 Wait… What’s a Webhook?

Let me explain it the way I finally got it:

Imagine you order food from a restaurant (you = your backend app). You don’t want to keep calling them to ask, "Is the food ready yet?"

Instead, you tell them: “Here’s my number. Just call me when the food is ready.”

That call is the webhook.

In my case, Paystack is the restaurant. After the payment, it sends a POST request to my backend automatically, containing details of the transaction.

That way, even if a user closes their browser or their internet drops, my backend still gets notified when a payment succeeds and I don’t have to keep asking their API whether the transaction went through.

I made sure that the webhook was idempotent (fancy word for: “Don’t repeat yourself”).
Even if Paystack sends the same webhook multiple times, my backend only updates the invoice once.

👩🏽‍💻 Lessons I Learned

Test mode is a lifesaver. You can simulate payments without using real money.
Payment processing isn’t as scary as it sounds once you break it down.
Webhooks are super useful when you don’t want to poll third-party APIs.
Security matters cause I had to validate incoming webhook signatures to avoid spoofing.

I’m still early in my journey as a backend developer, but this week felt like a level-up, seeing my app respond to real-world actions like a payment, and handle them intelligently.

💬 Now Share With Me

Have you tried integrating payment in your project? What platform did you use (Paystack, Stripe, Flutterwave…)? What was your first challenge?

Let me know in the comments or feel free to ask questions if you’re about to try it!

Bringing .populate() & .virtual() to The Party

Dorcas Nyamekye Quaye — Sun, 27 Jul 2025 13:06:17 +0000

This week, I got the concept of .populate() and .virtual() in Mongoose, and it clicked with a Wi-Fi analogy.

📡 Picture This…

Imagine your Wi-Fi router is a Track in your database. It doesn’t store a list of who’s connected. It just exists.

Now, picture your laptop as Courses. It knows what Wi-Fi it's connected to. That means the Course will have a field like track: Types.ObjectId.

So:

Your Course (laptop) remembers which Track (router) it’s connected to.
If you want to show more about the track (like its name), you just .populate() it.
It’s like your laptop saying:

“I’ve saved this Wi-Fi ID. Show me more about it.”

That’s .populate(). It fetches full data from the referenced document.

🔄 Now flip it…

Let's go back to the router (Track). It doesn’t store a list of all devices connected to it. But you can make it show them with .virtual().

You define a virtual field like:

trackSchema.virtual('courses', {
  ref: 'Course',
  localField: '_id',
  foreignField: 'track'
});

Then when you fetch a track and call .populate('courses'), it goes like:

“Okay, let me go and find all Courses where track === my ID and list them here.”

So .virtual() doesn’t store the connection. It just knows where to look.

😎 Why It Matters

Devices (Course) use .populate() because they know what router (Track) they’re connected to.

The Router (Track) uses .virtual() because it doesn’t know who’s connected, but it can go look.

.virtual() keeps your document clean. That means when you check your Track documents in the database, you won’t find a bloated list of every related Course inside each one.

Real-world backend structure is all about scalability and efficiency.

.virtual() is scalable in action.

So for anyone trying to get their head around Mongoose relationships?

Just remember:

Devices populate. Router virtual.

Postman Was on raw>Text... and Not raw>JSON

Dorcas Nyamekye Quaye — Fri, 18 Jul 2025 12:43:16 +0000

Let me save you some time. I spent hours debugging my backend routes, thinking the problem was my code, only to find out it was something way simpler.

I was testing protected routes like:
GET /auth-user
PUT /update-profile

These routes required a valid JWT and expected a properly formatted request body (JSON). My backend was using:

app.use(express.json());

And inside my controller, I was accessing data from req.body.

Despite everything looking fine in the code, my request kept failing with errors like:

{
  "message": "Unauthorized: No user ID found"
}

Or worse, the route would hit, but the body would be undefined.

I retested token flow, reconfigured middlewares, re-checked routes and controllers. But nothing worked.

😫 The Real Issue? Postman Was Set to Text, Not JSON

Yup. That was it.
In Postman, under Body > raw, I had left it on Text.
So instead of sending:

{
  "fullName": "Dorcas Q",
  "email": "dorcas@gmail.com"
}

It was sending plain text.
The backend, expecting JSON, saw... nothing. req.body was undefined.

When I finally realized I had left it in raw > Text instead of raw > JSON, I was both satisfied and so annoyed with myself. 😅
Like “Seriously? That’s what caused all this pain?”

🔍The Lesson I Learnt
Sometimes the problem isn’t in your backend logic. It’s in the tools you're using to test.
This reminded me how easy it is to overlook the simple things, especially when:

You’re reusing old tabs that default back to Text instead of JSON.
You’re testing authenticated endpoints, and your brain is fixated on JWT flows, headers, and controller logic.
You’re just so tired and have been debugging for hours (which I absolutely was).😁

Now? I no longer run a Postman test without double-checking that it's set to raw > JSON.
And if you made the same mistake, please don’t beat yourself up. It happens. A lot more often than you’d think.

✅ Final Tip
Before you start debugging controllers, token logic, or anything complex:

Double-check your Postman body type.
Make sure it’s raw > JSON.

Save yourself hours cause I wish I had.

☺️ Now Over to You
Have you ever been stuck for hours only to realize it was something tiny like this?
Let me know in the comments 👇

Creating Authentication Endpoints Using Node.js & Express.js

Dorcas Nyamekye Quaye — Thu, 17 Jul 2025 13:21:26 +0000

Imagine you are building an API with admin authentication. The kinds of auth endpoints you create will depend a lot on your app’s flow and needs.

Any time I look at a UI design or wireframe, I try to identify what endpoints are visibly needed. If it’s an admin authentication flow, the basics usually look like:

POST /signup
POST /verify-otp
POST /login
POST /forgot-password
POST /reset-password

But I don’t stop there. I always ask myself:

“What backend endpoints don’t appear on the UI but are still crucial for secure and smooth functionality?”

Sometimes I go blank, but that’s normal. In those moments, I just tell my AI assistant how I envision the project or hit up a dev friend in my DMs. If I’m working on something like a Student Management System, I usually break it down into categories:

Admin authentication
Lesson creation
Student enrollment, etc.

I either list what I think should be in that category and ask if I missed something, or I just ask, “What else would you add or recommend if given the chance?” You’d be surprised the gems you get back from those convos.

Doing this helps me build endpoints more intentionally, with security, scalability, and clean structure in mind.

Oh, and something I keep reminding myself:

It doesn’t have to be perfect before your first GitHub push... or the second... or the twelfth.

Interestingly, this week, I’ve been working on an auth workflow and was given a recommended list of endpoints to build. That alone made things feel so much clearer. Isn’t that cute? 😄

And funnily enough, that recommended list also opened my eyes to other useful endpoints, like:

POST /resend-verification-otp
POST /change-password

Sometimes, all it takes is a prompt from someone else, or a nudge from an AI to unlock that next layer of clarity.☺️

Progress over perfection. Always. Because even the most polished production apps didn’t start perfect. They evolved. Step by step. Tweak by tweak.