Forem: EMMANUEL UDODIRIM

📌 Building a Dynamic Profile API Endpoint: My HNG Stage Zero Journey

EMMANUEL UDODIRIM — Fri, 17 Oct 2025 07:59:04 +0000

I'm excited to share my latest project as part of the HNG Internship Stage Zero task! I built a simple yet functional REST API endpoint that serves dynamic content. This project helped me apply my backend development skills using Node.js and Express.

🚀 Project Overview

I created a /me endpoint that returns:

My personal information
Current UTC timestamp
A random cat fact that changes with each request

Here's what the response looks like:

{
  "status": "success",
  "user": {
    "email": "emmanueludodirim4@gmail.com",
    "name": "Emmanuel Udodirim",
    "stack": "Node.js/Express"
  },
  "timestamp": "2025-10-17T07:37:07Z",
  "fact": "Cats have 32 muscles in each ear."
}

💻 Tech Stack & Implementation

For this project, I used:

Node.js/Express: For creating the RESTful API
Axios: For fetching external data from Cat Facts API
Railway: For deployment and hosting

The implementation involved:

const express = require('express');
const axios = require('axios');
const app = express();

// GET /me endpoint
app.get('/me', async (req, res) => {
  try {
    // Fetch cat fact from external API
    const catFactResponse = await axios.get('https://catfact.ninja/fact', {
      timeout: 5000 // 5 second timeout
    });

    // Create response object
    const response = {
      status: 'success',
      user: {
        email: process.env.USER_EMAIL || 'emmanueludodirim4@gmail.com',
        name: process.env.USER_NAME || 'Emmanuel Udodirim',
        stack: process.env.USER_STACK || 'Node.js/Express'
      },
      timestamp: new Date().toISOString(), // Current UTC time in ISO 8601
      fact: catFactResponse.data.fact
    };

    res.status(200).json(response);
  } catch (error) {
    // Error handling
  }
});

🔍 Challenges & Learnings

During this project, I encountered several challenges:

Deployment Issues: Navigating Railway's configuration requirements
Port Configuration: Ensuring my app listened on the correct port

🎯 The Result

The final API is live at: https://hng-stage-zero-backend-production-1abf.up.railway.app/me

You can view the code on GitHub: https://github.com/emmytronix/hng-stage-zero-backend.git

📌 Building a Dynamic Profile API Endpoint: My HNG Stage Zero Journey

EMMANUEL UDODIRIM — Fri, 17 Oct 2025 07:59:04 +0000

🚀 Project Overview

I created a /me endpoint that returns:

My personal information
Current UTC timestamp
A random cat fact that changes with each request

Here's what the response looks like:

{
  "status": "success",
  "user": {
    "email": "emmanueludodirim4@gmail.com",
    "name": "Emmanuel Udodirim",
    "stack": "Node.js/Express"
  },
  "timestamp": "2025-10-17T07:37:07Z",
  "fact": "Cats have 32 muscles in each ear."
}

💻 Tech Stack & Implementation

For this project, I used:

Node.js/Express: For creating the RESTful API
Axios: For fetching external data from Cat Facts API
Railway: For deployment and hosting

The implementation involved:

const express = require('express');
const axios = require('axios');
const app = express();

// GET /me endpoint
app.get('/me', async (req, res) => {
  try {
    // Fetch cat fact from external API
    const catFactResponse = await axios.get('https://catfact.ninja/fact', {
      timeout: 5000 // 5 second timeout
    });

    // Create response object
    const response = {
      status: 'success',
      user: {
        email: process.env.USER_EMAIL || 'emmanueludodirim4@gmail.com',
        name: process.env.USER_NAME || 'Emmanuel Udodirim',
        stack: process.env.USER_STACK || 'Node.js/Express'
      },
      timestamp: new Date().toISOString(), // Current UTC time in ISO 8601
      fact: catFactResponse.data.fact
    };

    res.status(200).json(response);
  } catch (error) {
    // Error handling
  }
});

🔍 Challenges & Learnings

During this project, I encountered several challenges:

Deployment Issues: Navigating Railway's configuration requirements
Port Configuration: Ensuring my app listened on the correct port

🎯 The Result

The final API is live at: https://hng-stage-zero-backend-production-1abf.up.railway.app/me

You can view the code on GitHub: https://github.com/emmytronix/hng-stage-zero-backend.git

🏗️ Building Bivy Restaurant Microservices: My Role in the ERD Design & User/Menu Services

EMMANUEL UDODIRIM — Wed, 30 Jul 2025 19:17:45 +0000

In today’s fast-paced digital restaurant ecosystem, scalability and modularity are non-negotiable. That’s why our team is engineering Bivy Restaurant Microservices — a backend system powered by FastAPI (Python) and NestJS (TypeScript) to streamline restaurant operations.

As a core backend contributor, I took ownership of:

✅ Designing critical parts of the Entity-Relationship Diagram (ERD)
✅ Leading the User Service (authentication + RBAC)
✅ Architecting the Menu Service (dynamic categorization + inventory sync)

In this article, I’ll walk you through:

📐 My ERD design process
🛠 The microservices I own
🧭 Key technical decisions & what’s coming next

🧩 Designing the Database: My ERD Contributions

A well-designed database is the heartbeat of any microservice architecture. Here’s how I approached Bivy’s schema design.

👤 A. User Service Schema

The Challenge:
We needed secure authentication + flexible role management for admins, staff, and customers.

My Solution:

Built a normalized schema with USER and USER_ROLE tables

Designed it to be JWT-ready and role-extensible

erDiagram
USER {
int id PK
string email
string password_hash
string name
int role_id FK
}
USER_ROLE {
int id PK
string name
}
USER ||--o{ USER_ROLE : "has"

Why It Works:
✔ Passwords are stored using bcrypt hashing
✔ Roles are decoupled, enabling easy future expansions (like moderators or vendors)

🍽 B. Menu Service Schema

The Challenge:
Restaurants need menus that evolve — with categories, pricing, and availability — all while syncing with inventory without tight coupling.

My Solution:

Designed MENU_ITEM and CATEGORY tables

Introduced available flag for toggling visibility without touching inventory directly

erDiagram
MENU_ITEM {
int id PK
string name
float price
int category_id FK
bool available
}
CATEGORY {
int id PK
string name
}
MENU_ITEM }|--|| CATEGORY : "belongs_to"

Benefits:
✔ Fully decoupled from inventory DB
✔ Filtering is index-optimized for better performance

🔗 C. Cross-Service Collaboration

To maintain modularity, we ensured services communicate via event-driven architecture instead of direct DB joins.

Examples:

Orders reference both user_id and menu_item_id

Inventory syncs availability via Apache Kafka events

🚀 Microservices I Lead

🔐 A. User Service – FastAPI + JWT

Stack: Python, FastAPI, PostgreSQL, JWT

Core Features:

Secure Login/Registration

Role-Based Access Control (RBAC)

User profile endpoints

🍔 B. Menu Service – Dynamic & Real-Time

Stack: Python, FastAPI, Redis, PostgreSQL,

Core Features:

Dynamic menu categories

Real-time item availability toggling

Image upload support (S3 integration)

Workflow Example:

Admin adds a new item via /menu/items
Menu service emits Kafka event to inventory
If stock is available, item is flagged available=True and shown on the customer app

📍 Roadmap Ahead

🧭 User Service

[ ] OAuth 2.0 integration (Google / Facebook)

[ ] Passwordless login via magic links

🧭 Menu Service

[ ] Redis caching for fast menu queries

[ ] Seasonal menu activation (based on time or promo windows)

🧭 DevOps Goals

[ ] Kubernetes Helm Charts for scalable deployment

[ ] Monitoring via Prometheus + Grafana

🧠 Final Thoughts

By prioritizing clean ERD design, modular services, and event-driven architecture, Bivy is built to scale. This system will power:

💡 10,000+ concurrent users
⚙️ Zero-downtime deployments
🔄 Real-time menu updates across all customer touchpoints

What I Learned:

The power of database-first thinking

The value of loose coupling between services

The necessity of security-by-default principles

💬 Let’s Talk!

Have you ever built or contributed to a restaurant backend system?
How did you handle user roles, menu changes, or inventory sync?
Let’s discuss in the comments — I’d love to learn from your experience too.

📡 Connect with Bivy Tech

🟦 Follow us on X (Twitter)

🟦 Connect on LinkedIn

🏗️ Building Bivy Restaurant Microservices: My Role in the ERD Design & User/Menu Services

EMMANUEL UDODIRIM — Wed, 30 Jul 2025 18:27:58 +0000

As a core backend contributor, I took ownership of:

✅ Designing critical parts of the Entity-Relationship Diagram (ERD)
✅ Leading the User Service (authentication + RBAC)
✅ Architecting the Menu Service (dynamic categorization + inventory sync)

In this article, I’ll walk you through:

📐 My ERD design process
🛠 The microservices I own
🧭 Key technical decisions & what’s coming next

🧩 Designing the Database: My ERD Contributions

A well-designed database is the heartbeat of any microservice architecture. Here’s how I approached Bivy’s schema design.

👤 A. User Service Schema

The Challenge:
We needed secure authentication + flexible role management for admins, staff, and customers.

My Solution:

Built a normalized schema with USER and USER_ROLE tables

Designed it to be JWT-ready and role-extensible

erDiagram
USER {
int id PK
string email
string password_hash
string name
int role_id FK
}
USER_ROLE {
int id PK
string name
}
USER ||--o{ USER_ROLE : "has"

Why It Works:
✔ Passwords are stored using bcrypt hashing
✔ Roles are decoupled, enabling easy future expansions (like moderators or vendors)

🍽 B. Menu Service Schema

The Challenge:
Restaurants need menus that evolve — with categories, pricing, and availability — all while syncing with inventory without tight coupling.

My Solution:

Designed MENU_ITEM and CATEGORY tables

Introduced available flag for toggling visibility without touching inventory directly

erDiagram
MENU_ITEM {
int id PK
string name
float price
int category_id FK
bool available
}
CATEGORY {
int id PK
string name
}
MENU_ITEM }|--|| CATEGORY : "belongs_to"

Benefits:
✔ Fully decoupled from inventory DB
✔ Filtering is index-optimized for better performance

🔗 C. Cross-Service Collaboration

To maintain modularity, we ensured services communicate via event-driven architecture instead of direct DB joins.

Examples:

Orders reference both user_id and menu_item_id

Inventory syncs availability via Kafka events

🚀 Microservices I Lead

🔐 A. User Service – FastAPI + JWT

Stack: Python, FastAPI, PostgreSQL, JWT
Core Features:

Secure Login/Registration

Role-Based Access Control (RBAC)

User profile endpoints

🍔 B. Menu Service – Dynamic & Real-Time

Stack: Python, FastAPI, Redis (caching), PostgreSQL
Core Features:

Dynamic menu categories

Real-time item availability toggling

AWS S3 image upload support

Workflow Example:

Admin adds a new item via /menu/items
Menu service emits Kafka event to inventory
If stock is available, item is flagged available=True and shown on the customer app

📍 Roadmap Ahead

🧭 User Service

[ ] OAuth2.0 integration (Google, Facebook)

[ ] Passwordless login via magic links

🧭 Menu Service

[ ] Redis caching for fast menu queries

[ ] Seasonal menu activation (based on time or promo windows)

🧭 DevOps Goals

[ ] Kubernetes Helm Charts for scalable deployment

[ ] Prometheus + Grafana for monitoring

🧠 Final Thoughts

By prioritizing clean ERD design, modular services, and event-driven architecture, Bivy is built to scale. This system will power:

💡 10,000+ concurrent users

⚙️ Zero-downtime deployments

🔄 Real-time menu updates across all customer touchpoints

What I Learned:

The power of database-first thinking

The value of loose coupling between services

The necessity of security-by-default principles

💬 Let’s Talk!

📡 Connect with Bivy Tech

🟦 X (Twitter)

🟦 LinkedIn