DEV Community: Alaa Mekibes

Sakani: Building an Algerian Real Estate Platform with the MERN Stack

Alaa Mekibes — Sun, 30 Aug 2026 17:08:21 +0000

I built Sakani as a learning project to practice a full MERN stack setup end to end: a React frontend talking to a Node/Express/MongoDB backend, with proper auth, image uploads, and validation on both sides.

What Sakani does

It's a real estate listing platform. Users can sign up, browse properties with filters, view property details, and if they're logged in, list their own properties, edit them, and receive inquiries from interested buyers.

The backend: Express, MongoDB, and MVC

The backend is a REST API built with Node.js, Express 5, TypeScript, and MongoDB through Mongoose. I structured it around the classic MVC pattern, adapted for an API where there's no view layer, just JSON responses:

Request → Route → Middleware → Controller → Model → Database
                                    ↓
                             JSON Response

Models (src/models/) define the MongoDB schemas: user, property, inquiry.
Controllers (src/controllers/) hold the business logic. They never touch the database directly, they always go through a model.
Routes (src/routes/) map HTTP methods and paths to controllers, and chain middleware in front of them.
Middleware (src/middleware/) handles auth checks, Zod validation, file uploads, and error handling, all reusable across routes.

Here's what a typical route looks like, stacking middleware before the actual logic runs:

router.post('/',
    authMiddleware,           // 1. verify JWT
    upload.array('images'),   // 2. handle file upload
    validate(schema),         // 3. validate body with Zod
    propertyController.create // 4. run business logic
);

A few things I focused on:

Auth: JWT stored in an httpOnly cookie, so it can't be read or stolen by client-side JavaScript. Passwords are hashed with bcryptjs before ever touching the database.
Image uploads: multer handles incoming files, and multer-storage-cloudinary sends them straight to Cloudinary without saving anything to local disk first.
Validation: every request body, query, and param that matters gets checked with Zod through a small reusable validate() middleware.
Consistent responses: every endpoint returns the same shape through an ApiResponse helper, so the frontend always knows what to expect, whether it's a success, a validation failure, or an error.
Custom errors: instead of scattering status codes everywhere, I use error classes like NotFoundError, ConflictError, and UnauthorizedError that a global error handler catches and turns into proper responses.

The frontend: React, TanStack Router, and TypeScript

The frontend is React 19 with TypeScript, built with Vite, and it leans heavily on the TanStack ecosystem:

TanStack Router for file-based routing. The folder structure under src/routes/ defines the actual routes, and a Vite plugin auto-generates the route tree on every save.
TanStack Form for handling forms like create/update property and login/signup, paired with Zod for validation.
TailwindCSS + DaisyUI for styling, so I get ready-made components like navbars and cards without writing everything from scratch.

Some of the pieces I'm proud of:

A centralized api.ts fetch wrapper, so every request in the app goes through the same place and automatically includes cookies for auth. It exposes simple methods like api.get(), api.post(), and api.upload() for multipart image uploads.
Route-level auth protection, where a route simply declares what it needs and gets redirected if the condition fails:

beforeLoad: ({ context }) => {
    if (!context.isAuthenticated) throw redirect({ to: '/login' });
}

A global AuthContext that fetches the current user on app load to restore the session from the cookie, so refreshing the page doesn't log you out.
Search param validation, so filters on the properties page are validated with a Zod schema, and anything invalid is just silently ignored instead of crashing the page.

How the two sides talk to each other

The frontend never touches MongoDB directly, obviously. Every interaction goes through the REST API: things like listing properties with filters, creating a property with images, or sending an inquiry to a property owner. The API responses are typed on the frontend through shared interfaces, so what the backend sends and what the frontend expects stay in sync.

What I learned

How to structure a real backend around MVC instead of dumping everything into route handlers
How to handle authentication properly with JWT in httpOnly cookies instead of localStorage
How to wire up image uploads that go straight to a cloud storage service without touching my own server's disk
How file-based routing works in TanStack Router and how to protect routes based on auth state
How to keep validation consistent by using the same Zod schemas as the single source of truth for what "valid data" means
How much smoother frontend and backend development get when responses follow one consistent shape

Try it yourself

If you're learning MERN, I'd recommend picking a real-world domain like this one (listings, bookings, marketplaces) since it naturally forces you to deal with auth, file uploads, filtering, and relationships between resources, all the stuff that makes a project feel like more than a to-do list.

Frontend: github.com/alaa-mekibes/sakani-frontend-react
Backend: github.com/alaa-mekibes/sakani-backend-mongoose 🏠

I Built an IPv4 Subnet Calculator with Vanilla JS and OOP

Alaa Mekibes — Sat, 29 Aug 2026 15:00:15 +0000

Subnetting is one of those networking topics that sounds simple until you actually have to calculate a network address, broadcast address, and usable host range by hand. So I built a tool to do it for me, and along the way used it to practice Object-Oriented Programming in plain JavaScript: the IPv4 Subnet Calculator.

No frameworks, no libraries. Just HTML, CSS, and JavaScript classes, running entirely in the browser.

What it does

You give it an IP address in CIDR notation, something like 198.51.100.7/18, and it gives you back:

Network address
Broadcast address
Subnet mask
Wildcard mask
First and last usable host
Total usable hosts
Both decimal and binary formats
The IP address type (private, public, loopback, and so on)

You can also export the result as a PDF if you need to save or share it.

Why OOP for a calculator?

Instead of writing one big function that does everything, I structured the logic around classes:

class IpAddress {} // Base class for IP address operations
class NetworkComponents extends IpAddress {}
/*
- Handles common network components
- Calculates network address
- Handles subnet mask operations
- Calculates wildcard mask
- Calculates broadcast address
- Determines first/last usable hosts
*/

IpAddress handles the basics, parsing the IP, converting between decimal and binary. NetworkComponents extends it and adds all the subnetting logic on top. This kept things organized: if I needed to fix how the broadcast address was calculated, I knew exactly where to look, without touching the parsing code.

How the actual calculation works

Here's the logic, explained simply, step by step:

Parse the input: split the CIDR string (198.51.100.7/18) into the IP octets and the prefix length.
Convert to binary: turn the IP into its binary form. The first n bits (based on the prefix) are the network part, the rest are the host part.
Build the subnet mask: set the first n bits to 1 and the rest to 0. So /18 gives 255.255.192.0.
Build the wildcard mask: it's just the reverse of the subnet mask, subtract each octet from 255. So 255.255.192.0 becomes 0.0.63.255.
Get the network address: keep the network part of the IP, and set all host bits to 0.
Get the broadcast address: keep the network part, but set all host bits to 1 instead.
Count the hosts: 2^(number of host bits) - 2. The minus 2 accounts for the network and broadcast addresses, which can't be assigned to devices.

Detecting the IP address type

One feature I added on top of basic subnetting is a whichType() method that classifies the IP itself, not just the subnet. It checks the address against the standard ranges in order:

Private: 10.x.x.x, 172.16.x.x through 172.31.x.x, 192.168.x.x
Loopback: 127.x.x.x, used for testing on your own machine
Link-local: 169.254.x.x, used when a device can't get an IP automatically
Multicast: 224.x.x.x through 239.x.x.x, used for group communication like streaming
Broadcast: 255.255.255.255
Reserved: a handful of special ranges set aside for documentation, testing, or future use, like 0.x.x.x, 192.0.2.x, and 198.51.100.x
Public: if none of the above match, it's a normal internet-facing address, like 8.8.8.8

What I learned

How subnetting actually works at the bit level, instead of just plugging numbers into an online calculator
How to structure a small project with real class inheritance in vanilla JS, without reaching for a framework
How to convert between decimal and binary and manipulate bits directly in JavaScript
How networking concepts like private ranges, loopback, and multicast map to real address rules
How to add a simple PDF export using nothing but the browser's own print dialog

Try it yourself

If you're learning subnetting, I'd honestly recommend building your own calculator instead of just using one. Working through the binary conversion, the mask logic, and the address classification by hand is what actually made the concepts stick for me.

Check out the code here: github.com/alaa-mekibes/IPv4-calculator 🌐

🐸 I Built a Mini Compiler From Scratch, Here's What I Learned

Alaa Mekibes — Sat, 29 Aug 2026 00:36:53 +0000

Compilers always felt like this mysterious black box to me. Code goes in, magic happens, a program comes out. So for a compiler design assignment, I built one myself: Frog Mini Compiler, a compiler for "Frog," a small teaching language given to us for the assignment.

No frameworks, no compiler-building libraries. Just TypeScript, HTML/CSS, and the three classic phases every compiler goes through: lexical analysis, syntax analysis, and semantic analysis.

So what is "Frog"?

Frog is a simple language defined in our university assignment. It supports variables, printing, if/else statements, and a repeat-until loop. I think it's inspired by Pascal.. here's what a Frog program looks like:

FRG_Begin
FRG_Int i, j #
i := 10 #
If [i < 20]
    FRG_Print "Small number" #
Else
    FRG_Print "Big number" #
FRG_End

A few things to notice:

Every program starts with FRG_Begin and ends with FRG_End
# marks the end of an instruction (like a ;)
:= is used for assignment
## starts a comment
Conditions go inside [ ]

The three phases, explained simply

1. Lexical Analysis (the Lexer)

This is the first step, and honestly the most satisfying one to build. The Lexer reads your code character by character and groups those characters into meaningful chunks called tokens.

So i := 10 # doesn't stay as raw text, it becomes something like: ID(i), ASSIGN, INTNUMBER(10), END.

The Lexer also has to be smart about small stuff:

Skip whitespace and comments (##) without producing junk tokens
Tell the difference between 3 (an int) and 3.14 (a real number)
Catch errors, like a string that never gets closed with a "

Basically: the Lexer's job is to turn a wall of text into a clean list of tokens the next phase can actually work with.

2. Syntax Analysis (the Parser)

Once I have tokens, I need to check: do they actually follow the grammar rules of Frog? That's the Parser's job.

Think of the Parser as a strict grammar teacher. It looks at the token stream and expects specific patterns:

After FRG_Int, it expects at least one identifier, maybe more separated by commas, then a #
After If, it expects [, then a condition, then ]
After an identifier, it expects := and an expression

If any of these patterns break, the Parser reports an error with the line number. The tricky part here was writing parseExpression() and parseFactor() so they could handle chained operations like x + 5 * 2, calling themselves recursively to build up the full expression.

3. Semantic Analysis (the "does this actually make sense" phase)

This is where the real logic lives, and it's also where the code actually executes.

The Semantic Analyzer keeps a symbol table, basically a dictionary that tracks every variable's name, type, whether it's initialized, and its current value. As it walks through the parsed program, it checks things like:

Was this variable declared before you tried to use it?
Was it initialized before you tried to print it?
Are you assigning the right type of value?

And then it just... runs the program. If statements branch based on evaluated conditions, Repeat/until loops keep executing until the condition is true (capped at 1000 iterations so a bug in my code doesn't freeze the browser), and expressions get evaluated with proper operator precedence: parentheses first, then *//, then +/-.

Tying it together with a simple UI

I wrapped all three phases in a small web interface. You can:

Upload a .frog file or type code directly
Run each phase on its own (Lexical, then Syntax, then Semantic) to see intermediate results before moving to the next

Seeing the token list, then the parse results, then the final output side by side made the whole "three phases" concept click way more than reading about it ever did.

What I actually learned

How tokenization really works, not just the theory
Why grammar rules matter and how a parser enforces them
How symbol tables track variable state during execution
How to implement control flow (if/else, loops) by manipulating indices into a parsed statement list
How to evaluate expressions correctly, respecting operator precedence
Why compilers are split into phases in the first place: each phase has one job, and that makes the whole thing easier to reason about and debug

Known limitations

This is a learning project, so it's intentionally simple:

No functions/procedures
Only int and real number types
No string operations beyond printing
Basic error recovery, it stops at the first semantic error per line
No optimization phase

Try it yourself

If you're curious how compilers work under the hood, I'd genuinely recommend building a tiny one like this. You don't need a fancy language, just pick 5-6 features (variables, print, if, loop) and force yourself to implement all three phases by hand. It's one of those projects where the "aha" moments come fast.

Check out the code here: github.com/alaa-mekibes/frog-mini-compiler 🐸

I Was Confused About Merise for Weeks. Here's Everything I Learned

Alaa Mekibes — Sun, 22 Mar 2026 19:33:29 +0000

When I started learning database design, my teacher kept saying "MCD, MLD, MPD" and I had no idea what any of that meant. I searched in English and found almost nothing. That's when I realized Merise is a French methodology, and most of the internet doesn't talk about it.

So I learned it the hard way. This is the guide I wish existed when I started.

What is Merise?

Merise is a French software and database design methodology created in the 1970s-80s. It's widely used in France and French-speaking countries, but almost unknown in the English-speaking world where people use ERD or UML instead.

The core idea of Merise is that you design your database in 3 levels, going from abstract to concrete:

Level	French Name	English Equivalent
MCD	Modèle Conceptuel de Données	Conceptual Data Model
MLD	Modèle Logique de Données	Logical Data Model
MPD	Modèle Physique de Données	Physical Data Model

Think of it like building a house:

MCD = the architect's sketch (ideas, no technical details)
MLD = the blueprint (structure, measurements)
MPD = the actual construction (specific materials, real tools)

Level 1 MCD (Modèle Conceptuel de Données)

MCD is a graphical representation that describes the data of a system and their relationships in an abstract way. You're not thinking about tables or code yet just what exists and how things relate.

Structure:

Rectangles = Entities (contain attributes describing their properties)
Ovals = Relationships/associations between entities (connected to entities with lines)
Cardinalities = Indicate the minimum and maximum number of relations between entities
Attributes = The properties inside each entity

Cardinality the hardest part:

Cardinality answers: "how many of X can be related to Y?"

The format is min,max on each side:

1,1 → exactly one (mandatory, unique)
0,1 → zero or one (optional, max one)
1,N → at least one, can be many
0,N → optional, can be many
N,N → many to many → becomes a junction table in MLD

Example:

1,N next to School → one school has many courses. 1,1 next to Course → one course belongs to exactly one school.

The N-N rule:

In MCD, N-N relationships stay as just an oval. You don't create a table for them yet that happens in MLD.

Level 2 MLD (Modèle Logique de Données)

MLD is the translation of the MCD into a model adapted to relational databases defining tables, columns, primary keys, foreign keys, and relationships between tables.

Structure:

Tables = Come from entities and associations of the MCD
Columns = Based on the attributes from the MCD
Primary Key (PK) = One or more unique attributes identifying each row
Foreign Key (FK) = Links one table to another
No data types yet, no indexes that's MPD

3 rules for converting MCD → MLD:

1) Many-to-One (N:1):
The primary key from the N side becomes a foreign key in the other table.

2) Many-to-Many (N:N):
A new junction table is created. It contains at minimum two foreign keys pointing to both entities. If the association has its own attributes, they go in this table too.

3) One-to-One (1:1):
The primary key of one entity becomes a foreign key in the other table.

Example the N-N becomes a real table:

In MCD you had:

In MLD this becomes 3 tables:

Teacher (id, name, specialty)
Class (id, name)
TeacherClass (id, teacher_id FK, class_id FK)

TeacherClass didn't exist in MCD as a table it was just an oval. Now it's a real table. (we can add some attributes if needed)

Level 3 MPD (Modèle Physique de Données)

MPD = MLD + everything specific to your database engine.

You add:

Data types (VARCHAR(255), INT, TIMESTAMP, BOOLEAN…)
Constraints (NOT NULL, UNIQUE, DEFAULT…)
Indexes
Engine-specific options (PostgreSQL vs MySQL vs SQLite)

Example:

MLD says:

User (id, email, password, role)

MPD says:

CREATE TABLE users (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  email VARCHAR(255) NOT NULL UNIQUE,
  password TEXT NOT NULL,
  role VARCHAR(20) NOT NULL DEFAULT 'STUDENT',
  created_at TIMESTAMP(6) DEFAULT NOW()
);
CREATE INDEX idx_users_email ON users(email);

If you use an ORM like Prisma, your Prisma schema is your MPD because it has types (@db.VarChar(255)), indexes (@@index), and database-specific decorators.

Why Is There No English Documentation?

Honestly, this frustrated me a lot. Every time I searched "MCD MLD database design" in English, I got nothing useful.

The reason is simple: Merise is French. It was created by French researchers, taught in French schools, and used by French companies. English-speaking developers grew up with ERD (Entity-Relationship Diagrams) and UML, which are different tools that do roughly the same thing.

It's not that Merise is bad it's actually very structured and clean. It's just that the internet is mostly in English, and English devs never learned it.

If this helped you, drop a comment. And if you know better Merise resources in English, please share them we need more.

The difference between for...of and for...in loops in JavaScript

Alaa Mekibes — Thu, 04 Dec 2025 22:59:36 +0000

When working with JavaScript, understanding the difference between for...of and for...in loops is crucial for writing clean, efficient code. While they might look similar, they serve different purposes and work with different data structures.

With Arrays:

for...of gives you the actual elements
for...in gives you the indices (as strings)

const data = ['apple', 'banana', 'cherry'];

for (let item of data) {
    console.log(item);
}
// Output:
// apple
// banana  
// cherry

const data = ['apple', 'banana', 'cherry'];

for (let index in data) {
    console.log(index);
}
// Output:
// 0
// 1
// 2

With Strings:

for...of gives you each char in the word
for...in gives you the indices (as strings)

const text = "hello";

for (let char of text) {
    console.log(char); // h, e, l, l, o
}

for (let index in text) {
    console.log(index); // 0, 1, 2, 3, 4
}

With Objects:

for ... of doesn't work directly with plain objects (This would throw an error)
for ... in gives you key value for each element

const person = { name: 'John', age: 30, city: 'NYC' };

// for...in works with objects
for (let key in person) {
    console.log(key, person[key]);
}
// Output: name John, age 30, city NYC

How to Reset a Forgotten MariaDB User Password

Alaa Mekibes — Sat, 14 Dec 2024 15:48:15 +0000

Did you or someone using MariaDB forget the password to an account? Don’t worry! Resetting a MariaDB user password on Linux is super easy. Here’s a quick guide with the commands and step-by-step instructions to help you out.

Change MariaDB password using command line

Open a terminal.
Stop the currently running MariaDB database.

sudo systemctl stop mariadb

Restart the database process, but this time use the --skip-grant-tables option. This lets you connect to the database without needing a password.

sudo mysqld_safe --skip-grant-tables --skip-networking

Now, open a new terminal.
Login to MariaDB as root. Don't worry, it won't ask you about the password.

mariadb -u root

Run the FLUSH PRIVILEGES command and then change the root password with the command below. Change this NEW_PASSWORD_HERE to your new password. Past these commands line by line inside MariaDB Monitor.

FLUSH PRIVILEGES;
ALTER USER 'root'@'localhost' IDENTIFIED BY 'NEW_PASSWORD_HERE';
exit

Close your first terminal.
Stop the current mysqld process properly, and then restart your MariaDB server. Line by line.

sudo pkill mysqld 
sudo systemctl start mariadb

Congratulations! You’ve successfully changed the password. Now, go ahead and test it out!

mariadb -u root -p

Thanks for reading!