As part of my HNG13 Backend Internship, I was tasked with building a RESTful API that returns profile information along with a dynamic cat fact. While this might sound straightforward, the real challenge was to implement it using the Model-View-Controller (MVC) architectural pattern—a design pattern that's fundamental to building scalable, maintainable web applications.

In this post, I'll walk you through my entire development process, the challenges I faced, architectural decisions I made, and most importantly, what this experience taught me about professional backend development.

🎯 The Task Requirements

The requirements were clear but deceptively simple:

1. Create a /me endpoint that returns my profile information

2. Include a dynamic timestamp (updates with each request)

3. Fetch and display a random cat fact from an external API

4. Implement the solution using MVC architecture

5. Handle errors gracefully with proper fallback mechanisms

Expected Response Format:

{
  "status": "success",
  "user": {
    "email": "osuolaleabdullahi@gmail.com",
    "name": "Jelili Abdullahi A.",
    "stack": "Node.js/Express"
  },
  "timestamp": "2025-10-16T17:57:25.242Z",
  "fact": "Cats spend 70% of their lives sleeping!"
}

🤔 Understanding MVC Architecture

Before diving into code, I spent time understanding what MVC actually means in the context of a Node.js/Express API. Here's what I learned:

Model 🗄️

• Represents the data structure and business logic

• In my case: User.js defines the user data structure and methods to retrieve user information

• Handles data validation and manipulation

View 📱

• In REST APIs, the "view" is the JSON response format

• Controls how data is presented to the client

• Handled in the controller layer

Controller 🎛️

• Acts as the middleman between models and the client

• Processes incoming HTTP requests

• Calls services/models to get data

• Formats and sends responses

🏗️ Project Architecture

I organized my project into a clean, modular structure:

hng13-profile-task-0/
│
├── index.js                    # Application entry point
├── config/                     # Configuration files
│   └── constants.js           # API URLs, timeouts, fallback messages
├── models/                     # Data models
│   └── User.js                # User model with business logic
├── controllers/                # Request handlers
│   └── profileController.js   # Profile endpoint controller
├── routes/                     # Route definitions
│   └── profileRoutes.js       # Profile routes
├── services/                   # Business logic & external APIs
│   └── catFactService.js      # Cat Facts API integration
└── middlewares/                # Custom middlewares
    └── errorHandler.js        # Error handling middleware

This structure ensures separation of concerns—each file has a single, well-defined responsibility.

💻 Implementation Journey

Step 1: Setting Up the Foundation

I started by creating the entry point (index.js) and establishing the basic Express server:

const express = require("express");
const app = express();

// Configuration
const { PORT } = require("./config/constants");

// Middlewares
const { errorHandler, notFoundHandler } = require("./middlewares/errorHandler");

// Routes
const profileRoutes = require("./routes/profileRoutes");

// Apply middlewares
app.use(express.json());

// Mount routes
app.use("/", profileRoutes);

// Error handling (must be last)
app.use(notFoundHandler);
app.use(errorHandler);

// Start server
app.listen(PORT, () => {
  console.log(`Server is running on port ${PORT}`);
  console.log(`Environment: ${process.env.NODE_ENV || "development"}`);
});

Key Decision: I made sure error handlers are registered last in the middleware chain. This is crucial because Express processes middleware in order, and error handlers need to catch errors from all previous middleware.

Step 2: Creating the User Model

The User model encapsulates user data and provides methods to work with it:

class User {
  constructor(email, name, stack) {
    this.email = email;
    this.name = name;
    this.stack = stack;
  }

  // Get user data as plain object
  toJSON() {
    return {
      email: this.email,
      name: this.name,
      stack: this.stack,
    };
  }

  // Static method to get current user
  static getCurrentUser() {
    return new User(
      "osuolaleabdullahi@gmail.com",
      "Jelili Abdullahi A.",
      "Node.js/Express"
    );
  }
}

module.exports = User;

Why a class? Using a class provides a clear structure and makes it easy to add validation logic, computed properties, or database integration in the future. The toJSON() method ensures consistent data formatting.

Step 3: Building the Cat Fact Service

This was one of the most interesting parts. I needed to:

• Make HTTP requests to an external API

• Handle timeouts (external APIs can be slow)

• Provide fallback data if the API fails

const axios = require("axios");
const {
  CAT_FACT_API_URL,
  API_TIMEOUT,
  FALLBACK_MESSAGES,
} = require("../config/constants");

class CatFactService {
  static async getCatFact() {
    try {
      const response = await axios.get(CAT_FACT_API_URL, {
        timeout: API_TIMEOUT, // 5 seconds
      });

      const fact = response?.data?.fact;

      if (!fact) {
        throw new Error("No fact in response");
      }

      return fact;
    } catch (error) {
      console.error("Error fetching cat fact:", error?.message);
      return this.getFallbackMessage();
    }
  }

  static getFallbackMessage() {
    const randomMessage =
      FALLBACK_MESSAGES[Math.floor(Math.random() * FALLBACK_MESSAGES.length)];
    return `${randomMessage} (Cat Facts API temporarily unavailable)`;
  }
}

module.exports = CatFactService;

Key Learnings:

• Always set timeouts for external API calls (I used 5 seconds)

• Never trust external APIs to always be available

• Optional chaining (response?.data?.fact) prevents null reference errors

• Graceful degradation is better than complete failure

Step 4: Implementing the Controller

The controller orchestrates everything:

const User = require("../models/User");
const CatFactService = require("../services/catFactService");

class ProfileController {
  static async getProfile(req, res) {
    try {
      // Get user data
      const user = User.getCurrentUser();

      // Fetch cat fact
      const catFact = await CatFactService.getCatFact();

      const response = {
        status: "success",
        user: user.toJSON(),
        timestamp: new Date().toISOString(), // Dynamic timestamp
        fact: catFact,
      };

      res.status(200).json(response);
    } catch (error) {
      console.error("Error in getProfile:", error?.message);

      // Even in case of error, return a valid response with fallback data
      const user = User.getCurrentUser();
      const fallbackFact = CatFactService.getFallbackMessage();

      res.status(200).json({
        status: "success",
        user: user.toJSON(),
        timestamp: new Date().toISOString(),
        fact: fallbackFact,
      });
    }
  }
}

module.exports = ProfileController;

Important Decision: I decided to always return a 200 status even if the cat fact API fails. Why? Because the core functionality (returning profile data) is working. The cat fact is a nice-to-have feature, not a critical one. This is called graceful degradation.

Step 5: Setting Up Routes

Simple and clean route definition:

const express = require("express");
const router = express.Router();
const ProfileController = require("../controllers/profileController");

// GET /me - Get user profile with cat fact
router.get("/me", ProfileController.getProfile);

module.exports = router;

Step 6: Configuration Management

I centralized all configuration in one file:

module.exports = {
  PORT: process.env.PORT || 3000,
  CAT_FACT_API_URL: "https://catfact.ninja/fact",
  API_TIMEOUT: 5000,
  FALLBACK_MESSAGES: [
    "Cats are amazing creatures!",
    "Did you know cats have been companions to humans for over 9,000 years?",
    "A group of cats is called a 'clowder' - isn't that purr-fect?",
    "Cats spend 70% of their lives sleeping - living the dream!",
    "Fun fact: Cats have a third eyelid called a nictitating membrane!",
  ],
};

Why? This makes it easy to change configuration without touching the code. Want to change the timeout? Modify one number in one file. Want to add more fallback messages? Just add them to the array.

Step 7: Error Handling Middleware

Proper error handling is what separates amateur code from production-ready code:

// Global error handling middleware
const errorHandler = (err, req, res, next) => {
  console.error("Global error handler:", err.stack);

  res.status(err.status || 500).json({
    status: "error",
    message: err.message || "Internal server error",
  });
};

// 404 Not Found handler
const notFoundHandler = (req, res, next) => {
  res.status(404).json({
    status: "error",
    message: "Route not found",
  });
};

module.exports = {
  errorHandler,
  notFoundHandler,
};

🧪 Testing the API

I tested the endpoint using curl:

curl http://localhost:3000/me

Successful Response:

{
  "status": "success",
  "user": {
    "email": "osuolaleabdullahi@gmail.com",
    "name": "Jelili Abdullahi A.",
    "stack": "Node.js/Express"
  },
  "timestamp": "2025-10-16T18:23:45.123Z",
  "fact": "Cats can jump up to six times their length."
}

I also tested edge cases:

• ✅ What happens if the Cat Facts API is down? → Fallback message works

• ✅ What happens if the API takes too long? → Timeout kicks in after 5 seconds

• ✅ What if I hit a non-existent route? → Returns proper 404 error

• ✅ Does the timestamp update on each request? → Yes!

• ✅ Does each request get a different cat fact? → Yes!

🎓 Key Learnings

This task taught me several valuable lessons:

1. MVC Architecture is About Separation of Concerns

Each layer has a specific job:

• Models handle data structure

• Controllers handle request/response logic

• Services handle business logic and external integrations

• Routes define API endpoints

This separation makes code:

• Easier to test (you can test each layer independently)

• Easier to maintain (bugs are easier to locate)

• Easier to scale (you can add features without breaking existing code)

2. Error Handling is Not Optional

Professional applications handle errors gracefully. Key strategies:

• Always use try-catch blocks for async operations

• Set timeouts for external API calls

• Provide fallback data when possible

• Log errors for debugging but don't expose internal details to clients

3. Configuration Should Be Centralized

Having all constants in one file (constants.js) makes the application much easier to configure and maintain.

4. Design for Failure

External APIs will fail. Networks will be slow. Servers will crash. Design your application to handle these scenarios gracefully rather than failing completely.

5. Code Organization Matters

A well-organized codebase is easier to:

• Navigate

• Understand

• Debug

• Extend

• Work on as a team

🚀 Benefits of This Architecture

Maintainability

Each component is self-contained. Need to change how user data is retrieved? Modify the User model. Need to switch to a different cat facts API? Update the CatFactService.

Scalability

Want to add more endpoints? Create new controllers and routes. Need to add authentication? Add an auth middleware. The architecture supports growth.

Testability

Each layer can be tested independently:

• Test the User model in isolation

• Test the CatFactService with mocked HTTP calls

• Test the controller with mocked services

Team Collaboration

Multiple developers can work on different parts simultaneously without conflicts:

• One person works on models

• Another works on controllers

• Another works on services

🔄 What I Would Do Differently

If I were to extend this project, I would:

1. Add a Database: Currently, user data is hardcoded. Adding MongoDB/PostgreSQL would make it dynamic.

2. Add Validation: Use libraries like Joi or Express-validator to validate request data.

3. Add Testing: Write unit tests with Jest and integration tests with Supertest.

4. Add Logging: Replace console.log with a proper logging library like Winston or Pino.

5. Add Environment Variables: Use dotenv to manage sensitive configuration.

6. Add API Documentation: Use Swagger/OpenAPI to document the API.

7. Add Rate Limiting: Prevent abuse by limiting the number of requests per IP.

8. Add Caching: Cache cat facts to reduce external API calls.

🏆 Conclusion

This HNG13 task was more than just building a simple API—it was a lesson in professional software architecture. The MVC pattern might seem like overkill for a simple endpoint, but it demonstrates principles that scale to enterprise applications.

Key Takeaways:

• 🏗️ Architecture matters—even for small projects

• 🛡️ Always lan for failure (timeouts, fallbacks, error handling)

• 📦 Separation of concerns makes code maintainable

• 🔧 Configuration should be centralized

• ✨ Clean code is easier to understand, test, and extend

Building this API taught me that professional development isn't just about making things work—it's about making them work reliably, maintainably, and scalably.

If you're also participating in the HNG Internship or looking to hire backend developers, check out HNG Tech for talented developers like myself!

🤝 Connect With Me

• Email: osuolaleabdullahi@gmail.com

• Stack: Node.js/Express

What are your thoughts on MVC architecture? Have you used it in your projects? Share your experiences in the comments below! 👇

#HNG13 #NodeJS #Express #MVC #BackendDevelopment #API #JavaScript #WebDevelopment #SoftwareArchitecture #Internship