Forem: Dillibe Chisom Okorie

How I Finally Secured My impextech Node.js API (Without Losing My Mind to TypeScript) 🛡️

Dillibe Chisom Okorie — Mon, 06 Apr 2026 00:34:30 +0000

Let's be honest: building an API that "works on my machine" is a great feeling. But moving from an API that simply returns data to one that is actually secure, type-safe, and documented? That’s a whole different beast.

I am currently transitioning from medicine (I'm an MD) to backend engineering, and I’ve been building a gadget e-commerce engine called impextech. After finishing my unit tests and getting the MongoDB data layer working, I hit a wall.

My authentication logic was messy. My controllers were getting bloated. And testing my protected routes in Postman was driving me crazy.

Here is exactly how I cleaned up the mess, locked down my routes, and saved my sanity using express-jwt, TypeScript Generics, and Swagger.

1. Stopping the Copy-Paste Madness (JWT Middleware)

Originally, I was manually verifying JWTs inside my route handlers. If a user wanted to add a product, I’d check the header, decode the token, check their role... you know the drill. It was repetitive and prone to errors.

I finally removed all of that out and set up a proper middleware chain using express-jwt. I created a "Gate" that automatically handles the decryption, and then built a specific "VIP Checkpoint" for my admin routes.

It looks like this:

export const isAdmin = (req: JWTRequest<TokenPayload>, res: Response, next: NextFunction) => {
    if(req.auth && req.auth.role ==='admin'){
        next();
    }
        res.status(403).json({ message: 'Access denied. Admins only.' ,success:false});   

    }

Now, my route file is incredibly clean: router.post('/add', requireLogin, isAdmin, createProduct);

2. The TypeScript "Aha!" Moment 💡

If you write standard JavaScript, attaching user data to a request object is easy: req.user = decodedToken.

But if you use TypeScript, you know the pain I ran into next. The compiler started screaming at me because standard Express Request objects don't have an auth or user property.

The temptation to just slap an any type on the request and move on was huge. But I forced myself to dig into Generics (<T>) instead.

I defined exactly what my token payload looks like:

interface TokenPayload {
    id: string;
    email: string;
    role: string;
}

Then, I mapped it to the request: JWTRequest<TokenPayload>.

Suddenly, my IDE knew exactly what was inside req.auth. No more undefined property errors. The compiler now enforces my role-based access before a single line of business logic executes. Getting that autocomplete popup in VS Code for req.auth.role was one of the most satisfying moments of this project.

3. Putting the API on a Diet (The Service Layer)

As I added more security, my controllers were getting fat. They were handling HTTP status codes, parsing body data, and trying to do database lookups.

I decided to implement a Service Layer.

I split the codebase so that my Controllers only handle the web logic (req/res), and my Services handle the heavy lifting (database queries, business rules, password hashing).

If I ever want to write a background script to update inventory, I don't have to mock an HTTP request. I can just call the Service directly. It made the whole engine drastically easier to reason about

4. Throwing out my Postman Tabs (Enter Swagger)

Writing a secure API is great, but testing protected routes blindly is a nightmare. I was getting so tired of manually copying tokens, opening Postman, pasting them into the Authorization header, and hoping I didn't miss a character.

I took the time to integrate Swagger (OpenAPI).

Instead of guessing what my endpoints need, I now have an interactive UI. I can log in once, click the little "Authorize" padlock, paste my token, and instantly test any protected route directly from my browser.

In medicine, we use patient charts so every doctor knows exactly what's happening. Swagger is basically the medical chart for my API. It keeps everything readable and testable.

What I Learned

Moving from "it works" to "it's structured" is painful but worth it. By combining Type-Safe middleware with auto-generated documentation, the foundation of my engine is finally solid. Next up: finishing the CRUD operations and getting this thing connected to a frontend.

How do you guys handle your route protection? Do you roll your own middleware or lean on heavier packages like Passport? Let me know in the comments

How I Built a Robust Testing Suite for a Node.js API: A Guide to Data Integrity

Dillibe Chisom Okorie — Sun, 22 Mar 2026 07:39:18 +0000

Building a backend requires a disciplined approach to data modeling. If your schema relationships aren't validated correctly, the entire application logic becomes fragile during high-traffic operations.

For my latest project, Impextech, I implemented a professional-grade testing environment to move past manual verification. Here is a breakdown of how I used Jest and MongoDB Memory Server to ensure my data layer is bulletproof.

The "Virtual Database" Setup

I didn't want my tests polluting my production database. By using mongodb-memory-server, I created a virtual database in RAM that resets after every test execution.

beforeAll(async () => {
    mongoServer = await MongoMemoryServer.create({
        binary: { version: '6.0.4' }
    });
    await mongoose.connect(mongoServer.getUri());
});

Lesson Learned: The "Naming Conflict"

During development, I hit a path-resolution error. My test was looking for user but my schema used user_id. TypeScript caught the mismatch, but it was the Unit Test that proved the validation logic was failing because of it.

I’ve now aligned all models (Orders, Payments, Carts) to use consistent snake_case naming that mirrors the production API requirements.

Why I'm Testing Everything

Unit testing isn't just about finding bugs; it's about Defensive Design.

Validation: Ensuring quantity can't be less than 1.
Integrity: Trimming whitespace from emails automatically.
Constraints: Blocking unapproved payment methods via Enums.

With 22 green checkmarks in my terminal, the Impextech engine is officially ready for the next phase of API development.

Technical Reflection: Building the Impextech Database Architecture 🏗️

Dillibe Chisom Okorie — Mon, 09 Mar 2026 14:28:32 +0000

The completion of the data modeling phase for Impextech represents a significant shift from standard JavaScript scripting to robust, type-safe backend engineering. Here is a breakdown of the architectural decisions and technical milestones achieved.

1. Implementing Strict Type Safety (TypeScript)

The primary goal for this phase was to eliminate runtime data errors by moving to TypeScript.

Schema Inference: Instead of manually maintaining separate interfaces and schemas, I utilized Mongoose's InferSchemaType. This ensures that the TypeScript compiler and the MongoDB validation rules are always in sync, providing 100% type coverage for our product and user data.
IDE Support: This transition has significantly improved the development experience, offering real-time autocomplete and catching property mismatch bugs before they ever reach the execution phase.

2. Migration to ES Modules (ESM)

I successfully migrated the project from the legacy CommonJS (require) system to modern ES Modules (import/export).

Named Imports: By using named imports for Mongoose components, the codebase is now cleaner and optimized for tree-shaking, which reduces the application's overall memory footprint.
Modern Standards: Aligning with ESM ensures that Impextech is compatible with the latest Node.js performance updates and industry-standard module resolution patterns.

3. Collaboration and Configuration Optimization

Configuration is often the most challenging part of a TypeScript migration. When I encountered complex module resolution errors, I reached out to a fellow Backend Engineer for a code review.

tsconfig.json Evaluation: Through this collaboration, we optimized the tsconfig.json file—specifically the moduleResolution and target settings to ensure seamless integration between the TypeScript compiler and the Node.js runtime.
Key Takeaway: This experience reinforced the value of peer review and technical collaboration in resolving infrastructure bottlenecks.

4. Version Control & Git Strategy

To maintain a stable production environment, I implemented a dedicated branching strategy:

Feature Branching: All model development was conducted on a design-models branch.
Integration: Once the schemas were validated and the build scripts were passing, the branch was merged into main, ensuring a clean, documented history of the project's evolution.

Current Project Status

Database: MongoDB Atlas Connectivity Verified ✅

Architecture: TypeScript/ESM Pipeline Stabilized ✅

Models: Product and User Blueprints Finalized ✅

Next Steps: Developing the Controller layer and RESTful API routes to handle business logic and data flow.

Building Yarncom: From 0 to 22 Passing Integration Tests in 6 Days 🚀

Dillibe Chisom Okorie — Wed, 25 Feb 2026 20:56:48 +0000

Building a production-ready API from scratch is a rite of passage for every backend engineer. For my AltSchool Africa exam, I spent the last week building Yarncom — a secure, community-driven blogging engine.

Here is a breakdown of the architecture, the logic, and the environment "ghosts" I had to bust to get to a green terminal.

1. The Architecture: MVC and State Logic

To keep the system maintainable, I implemented a strict Model-View-Controller (MVC) pattern.

Models: Defined with Mongoose to handle complex schemas, including an Author reference that links Blogs to Users.
Controllers: The "brains" of the engine, managing the data flow and handling asynchronous handshakes with MongoDB.
State Machine: Articles transition between draft and published states. I implemented security guards to ensure drafts remain private while published content hits the public feed.

Automation with Mongoose Hooks

One of the most satisfying features was building an automated Reading Time Algorithm. Using a Mongoose pre-save hook, the engine analyzes the word count of the body text and calculates the estimate before the document is even saved:

blogSchema.pre('save', async function() {
    if (this.body) {
        const wordsPerMinute = 200;
        const words = this.body.split(/\s+/).length;
        this.reading_time = Math.ceil(words / wordsPerMinute);
    }
});

2. Stateless Security with JWT

I moved away from traditional sessions for this build, opting for JSON Web Tokens (JWT) stored in HTTP-only cookies.

This setup provides a stateless authentication layer that is both secure and scalable. The middleware checks for the token on every protected route, verifying the digital signature against a hidden JWT_SECRET before allowing the request to proceed to the controller.

3. Troubleshooting the "Ghosts"

In the journey to production, I encountered two specific bottlenecks that taught me more about systems than any documentation could:

The AirPlay Port Conflict (Port 5000)

I spent considerable time debugging a persistent 404 error where my server appeared to be running, but Postman couldn't find my routes.

The Discovery: macOS Monterey uses Port 5000 for the AirPlay Receiver.
The Fix: Migrating the local environment to Port 3000 resolved the conflict instantly.

Testing Isolation (Duplicate Keys)

While writing automated tests with Jest, I hit E11000 duplicate key errors.

The Fix: I implemented "Unique Data Assets" for the test suite, using timestamps (Date.now()) for user emails to ensure every test run had a clean, isolated database timeline.

4. Quality Assurance: 22 Integration Tests

I didn't consider the project finished until the logic was bulletproof. Using Jest and Supertest, I wrote a comprehensive suite of 22 tests covering:

Auth handshakes (Signup/Login/Logout).
Search and Regex accuracy.
Authorization checks (Ensuring User B cannot delete User A's work).
Read-count incrementation metrics.

5. Live Deployment

The final build is officially live on Render, connected to a MongoDB Atlas cluster.

Links:

GitHub Repository: Yarncom github repository

Live Demo: Yarncom demo

Conclusion

This project wasn't just about passing an exam; it was about mastering Systems Design and Environment Awareness. Building Yarncom proved that a robust backend isn't just written but built through persistence and rigorous testing.

Onward to the next build!

backend #node #javascript #mongodb #webdev #tutorial

Why Your Mongoose Hook is Returning 0 (The 'this' Lesson)

Dillibe Chisom Okorie — Fri, 13 Feb 2026 00:29:46 +0000

Building Yarncom Phase 2: Automation, Word Counts, and the "Arrow Function" Trap

I’m currently on Day 2 of building Yarncom, a community-driven blogging API. Yesterday, I handled the Security Handshake. Today, I faced the Logic Layer.
The goal was simple; Whenever a user saves a blog post, the API should automatically calculate the Estimated Reading Time based on a 200-words-per-minute average.
Here is the technical breakdown of the challenges I faced and the code that solved them.

1. The Automation Logic (The Pre-Save Hook)
Instead of forcing the user to tell us how long their post is, I used a Mongoose pre-save hook. This is a function that runs after the data is sent but before it’s persisted in the database.
blogSchema.pre('save', async function() { if (this.body) { const wordsPerMinute = 200; const words = this.body.split(/\s+/).length; this.reading_time = Math.ceil(words / wordsPerMinute); console.log( Calculated: ${this.reading_time} min); } });

2. The Trap: Arrow Functions vs. Regular Functions
This is where I got stuck. I initially used an Arrow Function: async () => { ... }.
The Problem: Arrow functions do not bind their own this. In Mongoose, this needs to point to the Document being saved. Because I used an arrow, this.body was undefined, and my terminal was silent.
The Fix: Always use a regular function() in Mongoose hooks if you need to access the data.

3. Cleaning up the "Next" Callback
I encountered the "next is not a function" error. This usually happens when you try to call a callback that isn't provided in an async context. By switching to a pure async function for my hook, I removed the need for the next() entirely. Mongoose is smart enough to wait for the Promise to resolve before moving to the save.

4. Result in Postman
After a few "failed renders," I finally got that beautiful 201 Created status. The response now includes:
"reading_time": 1"message": "Yarn successfully spun!"

What I Learned

Backend engineering is as much about Environment Awareness as it is about syntax. You have to know where your this is pointing and who is holding the "Baton" in the middleware chain.

node #javascript #mongodb #webdev #tutorial

Why Your Mongoose Hook is Returning 0 (The 'this' Lesson)

Dillibe Chisom Okorie — Fri, 13 Feb 2026 00:29:46 +0000

Building Yarncom Phase 2: Automation, Word Counts, and the "Arrow Function" Trap

4. Result in Postman
After a few "failed renders," I finally got that beautiful 201 Created status. The response now includes:
"reading_time": 1"message": "Yarn successfully spun!"

What I Learned

Backend engineering is as much about Environment Awareness as it is about syntax. You have to know where your this is pointing and who is holding the "Baton" in the middleware chain.

node #javascript #mongodb #webdev #tutorial

Building Yarncom: Phase 1 - The Authentication Handshake & The Port 5000 Ghost

Dillibe Chisom Okorie — Wed, 11 Feb 2026 15:31:46 +0000

Every developer remembers their first "real" project. For me, Yarncom is one of my first real projects. Instead of following a guided tutorial, I’m documenting a Progressive Journey of building a blogging API from scratch.

The Stack:

Engine: Node.js / Express
Database: MongoDB Atlas
Security: Bcryptjs & JWT

The Security Guard (Bcrypt & JWT)
I don't want to just save data; I want to secure it. I implemented a pre-save hook logic where passwords are scrambled using Bcrypt before they ever hit the database. For session management, I chose JWT. It’s like a digital keycard—you log in, you get a 1-hour pass, and you’re in.
The Port 5000 Mystery
If you're developing on a modern Mac, stay away from Port 5000. I ran into a wall where my server said "Running", but Postman said " 404 ".

The Culprit: AirPlay Receiver.

The Fix: const PORT = process.env.PORT || 3000;.

What’s Next?
Phase 2 involves the Blog Model and a custom Reading Time algorithm. Stay tuned as I weave this community together!

From Medical Doctor to Backend Engineer: Why I’m building my own E-commerce engine 🩺💻

Dillibe Chisom Okorie — Tue, 10 Feb 2026 14:26:28 +0000

Last year, I was graduating from medical school. Today, my "patients" are lines of code and database clusters.

I’m currently on a journey to transition into Backend Engineering
while enrolled at AltSchool Africa. But instead of just building "To-
Do" apps, I’ve decided to build something real: a full-scale online
store for my gadget business, impextech.

The Problem

Running a business like impextech involves a lot of moving parts—tracking inventory, managing sourcing, and handling customer orders. I realized that instead of using manual spreadsheets, I could build a custom solution that grows with me.

What I’ve Built This Week

I just finished the first major pillar of the backend: Database Persistence.

- Cloud Integration

I moved my product data from local memory to a live MongoDB Atlas cluster.

- Data Modeling

Using Mongoose, I built a schema that handles everything from MacBook specs to automated timestamps.

- Security

I implemented dotenv to ensure my business credentials stay private.

The "Doctor" Perspective

People often ask why I’m switching lanes. To me, medicine and engineering are cousins. Both require deep diagnosis, an understanding of complex systems, and a commitment to solving problems.

This store is just the beginning. My goal is to build a portfolio of software that solves real-world problems, and I’m documenting the entire process here.

I’d love to connect with other career-switchers or backend devs! What was the first "real" project you built?

#node #mongodb #showdev #backend #express #altschoolafrica #careerchange