Forem: Abdelhakim mohamed

How I Built a Multilingual Food Database Using a Local LLM on an AMD GPU

Abdelhakim mohamed — Thu, 22 Jan 2026 23:14:09 +0000

Two weeks ago, I launched my first app Nutix Ai, a calorie tracking app focused on simplicity. It's now at 200 downloads, which feels great for a first launch.

Today I want to share one specific part of the journey: building a food database that supports multiple languages (English, Arabic, Spanish) — not just English like most nutrition apps.

Why Multilingual?

Most calorie tracking apps have English-only databases, or their translations feel like afterthoughts. I wanted native speakers to actually be able to search for foods in their language from day one.

The Architecture

Simple setup:

Local LLM running on my AMD 9070XT (yes, not NVIDIA — and it worked great)
Base food data in English
LLM translates each entry to Arabic and Spanish
Output stored in my database

The Model Hunt (The Painful Part)

Finding the right model took longer than I expected.

Model	Speed	Translation Quality (especially Arabic)
DeepSeek 7B	Slow	Terrible
DeepSeek 8B	Slow	Terrible
DeepSeek 14B	Very slow	Still bad
Llama variants	Moderate	Poor
QWEN	Had high hopes	Performed worse than expected
Gemma3 7B	~200 tok/s	Good (1-5% error rate)
Gemma3 12B	~80 tok/s	Great

Gemma3 was the winner. The 7B was fast but had occasional errors. The 12B took about 2 seconds per food item but was much more reliable.

The Result

~6,000 foods translated into 3 languages in 4 hours, all generated locally on consumer hardware.

Known Issues & What's Next

Database size — 6K foods is a start, but I want to expand to 12+ languages and more regional foods
Search — The food search still needs work. Fuzzy matching across multiple languages is tricky

Looking for Suggestions

If you have ideas for:

Good sources of food/nutrition data
Improving multilingual search
Other languages I should prioritize

Drop them in the comments — I'd genuinely appreciate it.

You can check out the app here: Nutix on the App Store

Built a nutrition app with React Native + Expo SDK 54 that actually feels native on iOS 👀

Abdelhakim mohamed — Thu, 04 Dec 2025 01:34:03 +0000

Opening beta to the first 1000 users for free
Would love your feedback — what feels off? What could be better?
https://testflight.apple.com/join/ZVUxTEAt

DDoS Protection: How to Monitor, Detect, and Defend Against Attacks

Abdelhakim mohamed — Sat, 07 Jun 2025 01:09:13 +0000

The Midnight Server Meltdown: What To Do When Your Backend Goes Silent

Imagine this: it’s a peaceful night, maybe you’re winding down, enjoying a movie, or catching up on some sleep. Suddenly, your phone rings it's your client or your boss. Their voice is urgent:

“The server is down. Customers can’t access anything. Everything’s super slow!”

Your heart races. You scramble to your desk, half awake but fully alert now. You SSH into the server or open your monitoring dashboard nothing seems obviously broken. You check the logs they’re there, but not helpful. You hit a few endpoints they respond… eventually. What used to take 200ms is now crawling at 10 seconds or, even worse, timing out.

At this point, panic is knocking on your door.

You start digging deeper. CPU usage is spiking, memory is being eaten up, and your server is getting hammered with requests. But they aren’t normal requests they’re overwhelming, coming from a swarm of IPs. That’s when it hits you:

You're under a DDoS attack. Someone, somewhere, decided to bring your server to its knees.

Now the real question is what do you do to prevent this from happening again?

Set Up Rate Limiting
Limit how many requests each IP can make per second using Nginx. This helps slow down bots and flood attempts before they hurt your server.

If your using Nginx consider adding this inside nginx.conf

http {
  limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;

  server {
    listen 80;

    location /api/ {
      limit_req zone=mylimit burst=20 nodelay;
    }
  }
}

10r/s Limits each IP address to a maximum of 10 requests per second.
zone=mylimit:10m Creates a shared memory zone named mylimit that can track up to approximately 160,000 unique IP addresses with 10MB of memory.
burst=20 Allows short traffic spikes by permitting up to 20 excess requests to queue temporarily before triggering rate limiting.

Monitor Abusive IPs
Keep an eye on which IPs are getting rate-limited. If the same ones show up repeatedly, it’s a red flag something is trying to break in or overwhelm your system.

Add the following to your nginx.conf to enable logging:
This ensures that NGINX logs blocked or rate-limited requests along with the client’s IP address.

http {
  limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;
  log_format rate_limited '$remote_addr - $request - $status - $http_user_agent';

  map $status $log_rate_limit {
    503     1;
    default 0;
  }

  access_log /var/log/nginx/ratelimited.log rate_limited if=$log_rate_limit;

  server {
    listen 80;

    location /api/ {
      limit_req zone=mylimit burst=20 nodelay;
    }
  }
}

Automatically Ban Suspicious IPs
Use tools like fail2ban to detect patterns of abuse and block the source IP for a set period. This adds another layer of defense beyond just rate limiting.

sudo apt update
sudo apt install fail2ban

/etc/fail2ban/jail.conf: Default config
/etc/fail2ban/jail.d/: Your custom jail files
/etc/fail2ban/filter.d/: Contains filters

Let’s say we want to block any IP that gets rate-limited too often (503 status in your Nginx log).

1. Create a custom jail

/etc/fail2ban/jail.d/nginx-limit.conf

[nginx-limit]
enabled  = true
port     = http,https
filter   = nginx-limit
logpath  = /var/log/nginx/ratelimited.log
maxretry = 10
findtime = 60
bantime  = 600

Ban IPs that match the filter 10 times in 60 seconds
Ban them for 10 minutes

2. Create the filter file

/etc/fail2ban/filter.d/nginx-limit.conf

[Definition]
failregex = ^<HOST> - .+ - 503 - .*

This regex matches lines like:

192.168.1.5 - /api/endpoint - 503 - curl/7.58.0

It extracts the <HOST> (IP address) and counts the hits.

Start or Restart Fail2Ban

sudo systemctl restart fail2ban

Check Status and Banned IPs

sudo fail2ban-client status

Check specific jail:

sudo fail2ban-client status nginx-limit

Unban a specific IP (if needed):

sudo fail2ban-client set nginx-limit unbanip 192.168.1.5

Use reCAPTCHA to Stop Bots Cold
Especially for sensitive actions like login or guest access, adding Google reCAPTCHA can stop automated scripts in their tracks, without bothering real users much.

Thanks for reading my article 🙌

Understanding Express Routes, Controllers, and Services

Abdelhakim mohamed — Sat, 28 Sep 2024 21:51:42 +0000

Introduction

If you're new to Express.js or Node.js, you might have heard about "routes," "controllers," and "services." At first, these terms sound technical, but trust me understanding them can really transform how you build your apps. Not only will your code look cleaner, but it'll also make your life easier as your app grows. In this guide, we'll break down what each of these components does and why separating them is a game-changer for any Express project.

Let's start by setting up a basic Express app and organizing everything like a pro!

Setting Up Your Project

First things first let’s create a new Node.js project. Fire up your terminal and follow these steps:

Initialize your project by running:

   npm init -y

Install Express to get the magic going:

   npm install express

Now, let’s structure our project to keep things clean. Here’s how your folder setup should look:

my-express-app
│
├── src
│   ├── controllers
│   ├── routes
│   ├── services
│
├── app.js
└── package.json

We'll walk through what goes into each of these folders. Don't worry if this looks like a lot; it's easier than it seems!.

Routes: The Traffic Cops of Your App

Think of routes as traffic cops—they decide where each request should go. They don’t do much heavy lifting themselves but delegate the real work to controllers.

Here’s how you can create a basic route for user-related requests:

// src/routes/userRoutes.js
const express = require('express');
const router = express.Router();
const userController = require('../controllers/userController');

// Define routes
router.get('/users', userController.getAllUsers);
router.post('/users', userController.createUser);

module.exports = router;

In this example, when someone hits /users with a GET request, our app calls the getAllUsers function from the controller. Pretty neat, right?

Controllers: The Brains of the Operation

Now, controllers are where the logic happens. They take what the routes send their way and handle all the complex stuff like fetching data or saving a new user.

Let’s build a simple controller:

// src/controllers/userController.js
const userService = require('../services/userService');

exports.getAllUsers = (req, res) => {
  const users = userService.fetchUsers();
  res.status(200).json(users);
};

exports.createUser = (req, res) => {
  const newUser = userService.addUser(req.body);
  res.status(201).json(newUser);
};

Here, the controller is getting data from a service (which we'll talk about next) and sending a response back. Think of the controller as the middleman between routes and services—it doesn't handle data directly but knows who to ask.

Services: The Real Workers

Services handle the real business logic, like interacting with a database or managing data. This keeps your controllers nice and clean.

Check out this basic service that manages a list of users:

// src/services/userService.js
const users = [];

exports.fetchUsers = () => {
  return users;
};

exports.addUser = (user) => {
  users.push(user);
  return user;
};

Here, we’re storing users in an array (for simplicity). Services help keep your controllers lightweight and focused on handling requests instead of worrying about the data itself.

Bringing It All Together in `app.js`

Once you have your routes, controllers, and services set up, you need to wire everything together in your main application file (app.js):

// app.js
const express = require('express');
const app = express();
const userRoutes = require('./src/routes/userRoutes');

app.use(express.json());
app.use('/api', userRoutes);

const PORT = process.env.PORT || 3000;
app.listen(PORT, () => {
  console.log(`Server running on port ${PORT}`);
});

In this file, we tell Express to use our userRoutes for any requests that start with /api. This makes it easy to organize all your routes under one common base path.

How Your Final Directory Should Look

Once you've set up everything, your directory structure should look something like this:

my-express-app
│
├── src
│   ├── controllers
│   │   └── userController.js
│   ├── routes
│   │   └── userRoutes.js
│   ├── services
│   │   └── userService.js
│
├── app.js
└── package.json

Wrapping Up

By splitting your app into routes, controllers, and services, you've just taken the first step towards writing better, cleaner code! Not only does this make your project easier to manage now, but it also saves you headaches as your app gets more complex. Plus, your future self (and your teammates) will thank you!

Happy Coding😊