Houda Debza

Introduction au JavaScript : Au-delà du langage interprété

Mon, 15 Jun 2026 00:00:00 GMT

Introduction

Vous êtes surement tombé sur une définition de JavaScipt similaire a celle ci: JavaScript est un langage haut niveau, interprété, dynamique et le seul langage de programmation nativement compris par les navigateur ce qui en fait un élément fondamental du développement web moderne.

Cependant, cette définition est aujourd'hui incomplète. Les moteurs JavaScript modernes, comme V8 (Chrome), SpiderMonkey (Firefox), utilisent des techniques bien plus avancées que les interpréteurs basique pour améliorer les performances.

Donc en réalité, c'est quoi JavaScript ?

JavaScript est un langage de programmation de haut niveau, dynamique, multi-paradigme et principalement mono-thread. Il est exécuté par des moteurs spécialisés qui combinent interprétation et compilation JIT afin d'obtenir de bonnes performances tout en conservant la flexibilité du langage.

Autrement dit, JavaScript n'est plus simplement un langage interprété : il est aujourd'hui exécuté grâce à une combinaison intelligente d'interprétation et de compilation.

A noter que JavaScript n'est plus le seul language de programmation natif des navigateur,

JIT (Just In Time Compilation)

On a souvent entendu dire que JavaScript est un langage interprété. Historiquement, cette affirmation était correcte. Mais avant de comprendre le fonctionnement du JIT, il faut distinguer interpréteur et compilateur.

Interpréteur

Un interpréteur lit le programme et exécute les instructions au fur et à mesure.

Pour mieux visualiser ce processus, prenons l'exemple suivant :

let sum = 0;

for (let i = 0; i < 10; i++) {
  sum = sum + i;
}

Un interpréteur pur pourrait exécuter le programme de manière conceptuelle comme suit :

Ligne 1 : créer la variable sum = 0

Ligne 2 : créer la variable i = 0
          vérifier i < 10 → vrai

Ligne 3 : calculer sum + i
          stocker le résultat dans sum

Ligne 2 : i++
          vérifier i < 10 → vrai

Ligne 3 : calculer sum + i
          stocker le résultat dans sum

...

À chaque itération, les mêmes instructions doivent être relues et réanalysées avant d'être exécutées.

L'avantage est un démarrage rapide de l'exécution. En revanche, lorsque certaines portions du code sont exécutées des milliers ou des millions de fois, cette approche devient moins efficace.

Compilateur

Un compilateur adopte une approche différente.

Avant l'exécution, il analyse l'ensemble du programme puis le transforme dans une représentation plus proche de la machine.

Le processus est généralement :

Code source
      ↓
Analyse
      ↓
Compilation
      ↓
Code machine
      ↓
Exécution

L'avantage principal est la performance : le programme compilé s'exécute généralement beaucoup plus vite et les erreur sont detecter avant l'execution du programme.

L'inconvénient est qu'il faut attendre la fin de la compilation avant de commencer l'exécution.

JIT

Le JIT (Just In Time Compilation) combine les avantages des deux approches.

Lorsqu'un programme JavaScript démarre :

Le moteur lit rapidement le code.
Il génère du bytecode exécutable.
Le programme commence immédiatement à s'exécuter.
Le moteur observe quelles parties du code sont utilisées fréquemment.
Les portions les plus exécutées ("hot code") sont compilées en code machine optimisé le reste n'est pas optimiser.

Le processus peut être résumé ainsi :

Code JavaScript
        ↓
Parsing
        ↓
Bytecode
        ↓
Exécution
        ↓
Détection du code fréquent
        ↓
Compilation JIT
        ↓
Code machine optimisé

Cette stratégie permet d'obtenir un démarrage rapide tout en bénéficiant de performances proches des langages compilés.

Pour clarifier voyons ces deux examples:

console.log("test");
for (let i = 0; i < 10; i++) {
  console.log(test);
}

En executant ce code vous allez remarquer qui ca donne:

Si JavaScript été completement compilé, l'erreur aurait été afficher au tout debut de l'execution pas après le premier console.log.

const sum = 0;
for (let i = O; i < 10; i++) {
  sum = sum + i;
}

La boucle for est execute plusieur fois, le JIT va la considerer comme Hot code et generer son code machine.

Types dynamiques

JavaScript est un langage à typage dynamique.

Le type d'une variable est déterminé au moment de l'exécution et peut changer au cours du programme.

let value = 42; // Number

value = "Bonjour"; // String

value = true; // Boolean

Contrairement aux langages à typage statique comme Java ou C++, il n'est pas nécessaire de déclarer explicitement le type d'une variable.

Multi-paradigme

JavaScript supporte plusieurs styles de programmation.

Programmation procédurale

function add(a, b) {
  return a + b;
}

Programmation orientée objet

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

Programmation fonctionnelle

const numbers = [1, 2, 3];

const doubled = numbers.map((n) => n * 2);

Cette flexibilité permet aux développeurs de choisir le paradigme le plus adapté au problème à résoudre.

Unique Thread

JavaScript est principalement mono-thread.

Cela signifie qu'une seule instruction JavaScript est exécutée à la fois.

console.log("A");
console.log("B");
console.log("C");

La sortie sera toujours :

A
B
C

Pour gérer les opérations longues sans bloquer l'application, JavaScript s'appuie sur L'Event Loop, les Web APIs du navigateur et les mécanismes asynchrones tels que :

Callbacks
Promises
async/await

Garbage Collected

JavaScript dispose d'un ramasse-miettes (Garbage Collector).

Lorsqu'un objet n'est plus accessible par le programme, la mémoire qu'il occupe peut être automatiquement libérée.

let user = {
  name: "Alice",
};

// pas besoin de le faire manuellement, JavaScript le fait automatiquement quant une variables n'est plus utiliser
user = null;

Après cette affectation, l'objet original n'est plus référencé et pourra être supprimé par le Garbage Collector.

Cette gestion automatique de la mémoire simplifie considérablement le développement par rapport à des langages nécessitant une libération manuelle.

Récap en carte mentale

Histoire de JavaScript

JavaScript a été créé en 1995 par Brendan Eich chez Netscape.

Le langage a été développé en seulement dix jours afin d'ajouter de l'interactivité aux pages web, qui étaient jusque-là essentiellement statiques.

Au fil des années, JavaScript a évolué grâce à la standardisation ECMAScript :

1995 : création de JavaScript par Brendan Eich, en 10 jours, nomme Motcha puis LiveScript et finalement JavaScript pour des raison marketting car Java été trend a cette époque
1997 : première standardisation ECMAScript
2009 : ES5
2015 : ES6 (ECMAScript 2015)
Aujourd'hui : nouvelles versions publiées régulièrement (en general chaque année)

Initialement limité au navigateur, JavaScript est désormais utilisé côté serveur grâce à Node.js, ainsi que pour le développement mobile, desktop et même l'Internet des objets.

Conclusion

JavaScript est souvent décrit comme un langage interprété, mais cette définition ne reflète plus complètement la réalité actuelle. Les moteurs modernes utilisent des techniques sophistiquées combinant interprétation et compilation JIT afin d'offrir un excellent compromis entre rapidité de démarrage et performances d'exécution.

Grâce à son typage dynamique, son support de plusieurs paradigmes, son modèle d'exécution basé sur un thread principal et sa gestion automatique de la mémoire, JavaScript est devenu bien plus qu'un simple langage pour animer des pages web : il constitue aujourd'hui l'un des écosystèmes de développement les plus importants au monde.

Ce blog est le premier d'une serie dont on va decomposer chaque concept de JavaScript, Le prochain blog va attaquer les variable est type en profondeur.

NestJS JWT Auth with Email Verification

Tue, 05 May 2026 00:00:00 GMT

Introduction

Authentication is a feature that exists in most of the applications, so as a backend or full-stack developer, you need to implement it properly, not just “make it work”.

It’s one of the first features we build, and one of the easiest to get wrong. Especially at the beginning, a simple setup might seem sufficient but if not validated and structured, it can quickly open security issues and unreliable user flows.

There are lots of authentication strategies out there, and each has its own pros and cons. In this article, we will focus on one of the most popular approaches: JWT authentication.

We won’t just output a token and stop. Instead, we’re going to build a fuller flow with email verification. This makes sure that users really own the email addresses they sign up with, which is a necessary step in most real world applications.

The idea is to keep the implementation simple, but structured in a way that resembles how authentication is done in production systems.

What are we going to do

We are going to build a JWT auth in NestJS and React using passport-jwt and send a validation email to validate the user account using Resend.

Here is the pipeline we will follow:

[ User ]
   │
   │ Register
   ▼
[ Backend ]
   │
   │ Create account (unverified)
   │ Send verification email
   ▼
[ Email Inbox ]
   │
   │ Click verification link
   ▼
[ Backend ]
   │
   │ Validate account
   ▼
[ User ]
   │
   │ Login
   ▼
[ Backend ]
   │
   │ Generate JWT
   ▼
[ Authenticated User ]

In this first part we will only focus on the user registry, the envirenment setup and the email verification, we will implement the login in the second part.

Setting up the environment

To achieve this, we should first set up our project; in my case, I'm going to use a monorepo setup using Turborepo (you can also use separate projects for the frontend and backend). If you have any struggle setting up the monorepo, this article will help you: Setting Up TurboRepo Is Easy… Until You Add Another App

Create The Database module and the user schema

Initiating the Database

You can literally store your users in a table in memory, in a JSON file, or in any storage you prefer; for this example, I'm going to use a MySQL database with Drizzle as an ORM (feel free to use Prisma, TypeORM, ...).

First let's install the necessary dependencies:

cd apps/api
pnpm install drizzle-orm mysql2 dotenv @nestjs/config drizzle-kit

Create a .env file:

## .env
DATABASE_URL="mysql://root:root@localhost:3306/auth"
## the first root stands for the database user
## the second root stands for the database password
## auth is our database name
## 3306 is the database port

You can now create your database manually (either locally or using Docker) using your corresponding credentials, or you can make a Docker Compose file to create it and start it in the future (yes, I get you have too many steps to start, but it's a good future optimization).

Here is an example of the Docker Compose file (you can either create it in the project or even in another location):

## docker-compose.yaml
services:
  db:
    image: mysql:9.7
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: root
      MYSQL_DATABASE: auth
    ports:
      - '3306:3306'
    volumes:
      - mysql_data:/var/lib/mysql
    healthcheck:
      test: ['CMD', 'mysqladmin', 'ping', '-h', 'localhost', '-uroot', '-proot']
      interval: 10s
      timeout: 5s
      retries: 5

volumes:
  mysql_data:

and run it:

docker-compose up -d

Creating the database module

Now, our database is ready. We can create our database module by running the following:

nest g module db

The generated module code:

// db.module.ts
import { Module } from  '@nestjs/common';
@Module({
	providers:  []
})
export  class  DbModule {}

Since most of the future modules will depend on the database, we’ll add the @Global() decorator at the top of this module. This allows us to access it anywhere in the application without having to import it in every module.

Then we should define what this module will do in the providers:

// db.module.ts
import { Global, Module } from '@nestjs/common';
import { ConfigService } from '@nestjs/config';
import { drizzle } from 'drizzle-orm/mysql2';
import mysql from 'mysql2/promise';

@Global()
@Module({
  providers: [
    {
      inject: [ConfigService],
      useFactory: async (configService: ConfigService) => {
        const connection = await mysql.createConnection(
          configService.get<string>('DATABASE_URL')!
        );

        return drizzle(connection, {
          mode: 'default', 
        });
      },
    },
  ],
})
export class DatabaseModule {}

Our module uses the useFactory method, which allows us to dynamically create the database connection based on the value present in the .env file.

Finally, we need to give it a provider name, which NestJS will use to inject it in the other modules automatically, and then export the module.

The final database module:

// db.module.ts
import { Global, Module } from '@nestjs/common';
import { ConfigService } from '@nestjs/config';
import { drizzle } from 'drizzle-orm/mysql2';
import mysql from 'mysql2/promise';

export const DATABASE_CONNECTION = 'DATABASE_CONNECTION';

@Global()
@Module({
  providers: [
    {
      provide: DATABASE_CONNECTION,
      inject: [ConfigService],
      useFactory: async (configService: ConfigService) => {
        const connection = await mysql.createConnection(
          configService.get<string>('DATABASE_URL')!
        );

        return drizzle(connection, {
          mode: 'default', 
        });
      },
    },
  ],
  exports: [DATABASE_CONNECTION],
})
export class DatabaseModule {}

But if you try to start your application and hope that everything will work, I'm sorry to say it, but it won't since you have to register the config module in the app module (because we used it in the database module), like this:

// app.module.ts
import { Module } from  '@nestjs/common';
import { AppController } from  './app.controller';
import { AppService } from  './app.service';
import { DatabaseModule } from  './db/db.module';
import { ConfigModule } from  '@nestjs/config';

@Module({
	imports:  [
		ConfigModule.forRoot({
			isGlobal: true,
		}),
		DatabaseModule,
	],
	controllers:  [AppController],
	providers:  [AppService],
})
export  class  AppModule {}

Now you can run it and see that everything is going well; let's move to the next step.

Creating the database Schema

Right now we have a project and a database that are connected together, but we need a table in that database to store the users, so let's do it.

We need to create a schema file under the db module folder, like this:

// schema.ts
import {
	mysqlTable,
	varchar,
	boolean,
	timestamp,
	mysqlEnum,
} from  'drizzle-orm/mysql-core';

export  const  users  =  mysqlTable('users', {
	id:  varchar('id', { length:  36 }).primaryKey(),
	email:  varchar('email', { length:  255 }).unique().notNull(),
	password:  varchar('password', { length:  255 }).notNull(),
	role:  mysqlEnum('role', ['seller', 'customer']).notNull(),
	isVerified:  boolean('is_verified').default(false).notNull(),
	emailVerificationToken:  varchar('email_verification_token', { length:  255 }),
	emailVerificationExpires:  timestamp('email_verification_expires'),
	createdAt:  timestamp('created_at').defaultNow().notNull(),
});
export  type  User  =  typeof  users.$inferSelect;
export  type  InsertUser  =  typeof  users.$inferInsert;

If you noticed, I added a user type (I reused it from a marketplace project), so you can better understand role-based authentication.

We need to add it into the module provider:

// db.module.ts
return drizzle(connection, {
		schema,
		mode: 'default', 
});

Before we can generate and apply this migration. We should first create a drizzle config file, since drizzle doesn't know about your NestJS code; the config will allow it to know where your schema is and where to create the migration files. You need to create it in your backend root folder; it will contain the following:

// drizzle.config.ts
import  'dotenv/config';
import { defineConfig } from  'drizzle-kit';

export  default  defineConfig({
	dialect:  'mysql',
	schema:  './src/db/schema.ts', // make sure it matches your schema file path
	out:  './drizzle',
	dbCredentials: {
		url:  process.env.DATABASE_URL!,
	},
});

Then add migrate and generate the script into the package.json (you can run the Drizzle commands directly also, but if you are going to work in a team, it's better to treat the ORM as a black box).

// packages.json
"scripts": {
	...
	"db:generate": "drizzle-kit generate",
	"db:migrate": "drizzle-kit migrate"
},

And now we can run those two scripts in our terminal:

pnpm db:generate
pnpm db:migrate

If you are not sure whether the migration is applied, you can verify the tables of the database before we move to the auth part.

Authentication module

So, before starting the authentication module, let' install the required dependencies:

cd apps/api
pnpm install bcryptjs passport passport-jwt @nestjs/jwt @nestjs/swagger zod
## bcryptjs => hash password
## passport, passport-jwt, @nestjs/jwt => generate and manage the user access token
## swagger => a UI to test and document the API (you can skip it)
## zod => schema validation for incoming data

Now let's generate the module, service, and controller of our auth module using the Nest CLI:

nest g module auth  
nest g controller auth  
nest g service auth

And create our register's incoming data schema validation using Zod.

/* 
You can either: 
- create a validation folder in the backend root folder and put this file in it 
- or create it in the auth folder, 
- or if you are working under a monorepo, you can add a validation package that allows you to share the types between the frontend and backend and guarantees the consistency. 
- To make it easy to follow, I will create a validation folder in our backend and add this file into it.
*/
// auth.ts
import { z } from  'zod';
export  const  RegisterSchema  =  z.object({
	email:  z.string().email('Invalid email address'),
	password:  z.string().min(8, 'Password must be at least 8 characters'),
	role:  z.enum(['seller', 'customer'], { error:  'Role must be seller or customer' }),
});
export  type  RegisterInput  =  z.infer<typeof  RegisterSchema>;

Then create the register service:

// auth.service.ts
import { ConflictException, Injectable, Inject } from  '@nestjs/common';
import { eq } from  'drizzle-orm';
import * as  bcrypt  from  'bcryptjs';
import { users } from  '../db/schema';
import { DATABASE_CONNECTION } from  'src/db/db.module';
import { RegisterInput } from  '../../validation/auth';
import { randomBytes } from  'crypto';

@Injectable()
export  class  AuthService {
	constructor(@Inject(DATABASE_CONNECTION) private  readonly  db:  any) {}
	
	async  register(input:  RegisterInput):  Promise<{ message:  string }> {
		// check if the user already exists
		const  existingUser  =  await  this.db
			.select()
			.from(users)
			.where(eq(users.email, input.email))
			.limit(1);
		if (existingUser.length  >  0) {
			throw  new  ConflictException('User with this email already exist');
		}
		
		// hash the password
		const  hashedPassword  =  await  bcrypt.hash(input.password, 12);
		// generate user ID
		const  userId  =  randomBytes(16).toString('hex');

		//Insert the user into the database
		await  this.db.insert(users).values({
			id:  userId,
			email:  input.email,
			password:  hashedPassword,
			role:  input.role,
			isVerified: false,
			emailVerificationToken: null,
			emailVerificationExpires: null,
		});
		return {
			message:  'Registration successful',
		};
	}
}

Let's break down this code:

If you remember the database module we created and set here, we injected it with its provider name; I guess now it's clearer why we added that const.
We are checking if a user with the same email already exists in the db; if so, the user should be redirected to the login page.
If the user doesn't exist, then we should create it; we start by hashing the password and generating an ID for this new user.
Then we call our database to create an entry for this new user (the emailVerificationToken and emailVerificationExpires are set to null right now; we will update this when adding the email verification logic).

We finally need the register controller to handle the HTTP requests:

// auth.controller.ts
import { Body, Controller, Post } from  '@nestjs/common'; 
import { AuthService } from  './auth.service';
import  type { RegisterInput } from  'validation/auth';

@Controller('auth')
export  class  AuthController {
constructor(private  readonly  authService:  AuthService) {}
	@Post('register')
	async  register(@Body() body:  RegisterInput) {
		return  this.authService.register(body);
	}
}

Let's explain this code:

We injected our service into the controller.
We called our service register function inside the post request.
We added the @Post('register') decorator. This decorator tells NestJS that this method will handle HTTP POST requests sent to /auth/register

You can open Postman and test this endpoint, or as a bonus step, you can set up the Swagger UI in the main.ts

// main.ts
import { NestFactory } from  '@nestjs/core';
import { AppModule } from  './app.module';
import { SwaggerModule, DocumentBuilder } from  '@nestjs/swagger';

async  function  bootstrap() {
	const  app  =  await  NestFactory.create(AppModule);

	const  config  =  new  DocumentBuilder()
		.setTitle('API')
		.setDescription('WeStore marketplace API')
		.setVersion('1.0')
		.addBearerAuth()
		.addTag('Authentication', 'User registration')
		.build();

	const  document  =  SwaggerModule.createDocument(app, config);
	SwaggerModule.setup('docs', app, document);

	await  app.listen(process.env.PORT  ??  4000);
}
bootstrap();

And then add the appropriate decorators of swagger into your controller; it's a long list of decorators, so check my repo if you want to go further with swagger: jwt-auth-monorepo-nest-react

Now run the application and test the register endpoint with this json format:

{
  "email": "user@example.com",
  "password": "securePassword123",
  "role": "customer"
}

Everything works fine.

Email verification

I guess that you remember this in the auth service:

// auth.service.ts
//Insert the user into the database
await  this.db.insert(users).values({
	id:  userId,
	email:  input.email,
	password:  hashedPassword,
	role:  input.role,
	isVerified: false,
	emailVerificationToken: null,
	emailVerificationExpires: null,
});

We initially set the email verification token and its expiration to null since we hadn’t implemented the verification logic yet. Now, let’s add that functionality.

Install the dependencies

First let's start by installing the needed dependencies:

pnpm install resend

Getting an API key

Let's go to resend and create a new API key.

Once you get it, let's add it into the .env file:

// .env
DATABASE_URL=mysql://root:root@localhost:3306/auth

RESEND_API_KEY=re_..........
FROM_EMAIL=onboarding@resend.dev
## In development envirenment, emails are automatically sent from Resend’s default email. You can customize the sender address in production once you’ve added your domain.

Email module

Now let's generate a module and a service for our email sending verification process.

nest g module email
nest g service email

In the service let's add this.

//email.service.ts
import { Injectable } from  '@nestjs/common';
import { Resend } from  'resend';

@Injectable()
export  class  EmailService {
	private  readonly  resend  =  new  Resend(process.env.RESEND_API_KEY);
	async  sendVerificationEmail(email:  string, token:  string):  Promise<void> {
	const  verificationUrl  =  `${process.env.API_URL ?? 'http://localhost:4000'}/auth/verify-email?token=${token}`;
	const { error } =  await  this.resend.emails.send({
		from:  'auth <onboarding@resend.dev>',
		to:  email,
		subject:  'Verify your auth account',
		html:  `
			<div style="font-family:sans-serif;max-width:480px;margin:0 auto;padding:32px 24px">
				<h2 style="color:#09B1BA;margin:0 0 8px">Auth</h2>
				<p style="color:#111;font-size:16px;font-weight:600;margin:0 0 16px">Confirm your email address</p>
				<p style="color:#555;font-size:14px;line-height:1.6;margin:0 0 24px">
					Click the button below to verify your account. This link expires in 24 hours.
				</p>
				<a href="${verificationUrl}"
					style="display:inline-block;background:#09B1BA;color:#fff;text-decoration:none;padding:12px 28px;border-radius:8px;font-size:14px;font-weight:600">
					Verify email
				</a>
				<p style="color:#aaa;font-size:12px;margin:24px 0 0">
					If you didn't create an account, you can safely ignore this email.
				</p>
			</div>
			`,
	});

		if (error) {
			console.error('Resend error:', error);
			throw  new  Error(`Failed to send verification email: ${error.message}`);
		}
	}
}

This is a UI of the verification email that will be sent to the user (you can customize the UI).

If you noticed, there is verificationUrl that which takes a token, so let's go create the email verification logic that generates this token.

Email verification, auth service

Go back to the auth service; let's define the email verification function:

async  verifyEmail(token:  string):  Promise<{ message:  string }> {
	if (!token) {
		throw  new  BadRequestException('Verification token is required');
	}

	const  user  =  await  this.db
		.select()
		.from(users)
		.where(eq(users.emailVerificationToken, token))
		.limit(1);
		
	if (user.length  ===  0) {
		throw  new  NotFoundException('Invalid or expired verification token');
	}
	const  userRecord  =  user[0];
	if (
		userRecord.emailVerificationExpires  &&
		new  Date() >  userRecord.emailVerificationExpires
	) {
		throw  new  BadRequestException('Verification token has expired');
	}
	if (userRecord.isVerified) {
		throw  new  BadRequestException('Email is already verified');
	}
	await  this.db
		.update(users)
		.set({
			isVerified: true,
			emailVerificationToken: null,
			emailVerificationExpires: null,
		})
	.where(eq(users.id, userRecord.id));
	return {
		message:  'Email verified successfully. You can now log in.',
	};
}

let's explain this code

We first check if a token is provided in the request.
We query the database to find a user that has the same email verification token.
We check if the token has expired by comparing the current date with the expiration date stored in the database.
We also check if the user is already verified (no need to reverify).
If everything is valid, we mark the user as verified and remove the verification token and its expiration date (preventing reuse).

But it's checking a token that we didn't generate; let's add the generation logic in the register service function:

// auth.service.ts

// add this line to the constructor private  readonly  emailService:  EmailService,

// Note: in production ot's recommended to hash the email verification token, it's just a simplification for the tutaorial purpose.
const  emailVerificationToken  =  randomBytes(32).toString('hex');
const  emailVerificationExpires  =  new  Date(Date.now() +  24  *  60  *  60  *  1000); // 24 hours

const  userId  =  randomBytes(16).toString('hex');

await  this.emailService.sendVerificationEmail(
	input.email,
	emailVerificationToken,
);

await  this.db.insert(users).values({
	id:  userId,
	email:  input.email,
	password:  hashedPassword,
	role:  input.role,
	isVerified: false,
	emailVerificationToken,
	emailVerificationExpires,
});

I guess that this code need some clarification

We generate a random token that will be used to verify the user’s email.
Then we create an expiration date for the token (24 hours), you can skip this step, but it's improves security.
We store both the token and its expiration date in the database along with the user’s information (you remeber that in the verification we were checking the token).
After saving the user, we send a verification email that contains a link with the token. When the user clicks this link, it will trigger the verification process.

Some side note:

since we imported the email service in the auth service you need to make sure that you exported the email service in it's module and imported it in the auth module.

Test the email verification

First let add the controller endpoint that will allow us to test

@Get('verify-email')
async  verifyEmail(@Query('token') token:  string) {
	return  this.authService.verifyEmail(token);
}

Then let's create a new user with the email you used to authenticate to Resend and create the api key, since in dev mode it allows sending email only to that email.

In my side I checked that the email is sent, so it's working.

Conclusion

Thanks for reading this article; the second part will follow soon.

You can find the boilerplate of the full pipeline (with login and UI included) in my GitHub repo: GitHub

If you have any question or want to hire me, my contact infos are available on my blog/portfolio.

Cross-Platform Fake Profile Detection: Experimental Machine Learning Graduation Project

Fri, 24 Apr 2026 00:00:00 GMT

Introduction

After a long journey at the Higher School of Computer Science in Sidi Bel Abbès, I finally graduated on September 22, 2025.

In this blog, I will explain the steps I followed to build my graduation project, which was: “An experimental ML system for robust fake profile detection across social platforms using multi-strategy feature selection and model benchmarking”, using metaheuristic and machine learning methods.

Introduction
The Journey
The Problem I Tried to Solve
Data & Sources
Methodology Overview
System Implementation
Results
Discussion
Deployment
Improvements for Future Work
Conclusion

The journey

Although it was a long journey that took about 8 months of serious work, it’s the period where I evolved the most during my academic path.

It may look simple, you just have to follow this steps:

try something
criticize it
improve it
and repeat

But in reality, it’s much harder than that.

You constantly:

question your own work
go back and redo things from scratch
test multiple strategies that don’t always work
and spend hours waiting for results that might not always satisfies you

The first months felt like I wasn’t making real progress.
I was implementing metaheuristics in a generic, reusable way, but it didn’t produce immediate results. I was also trying to figure out the best direction to follow, which made things even more confusing.

But looking back, those were actually the months where I progressed the most.

They built the foundation for everything that came after. Once that part was done, the next steps became much easier and much faster.

The Problem I Tried to solve

There is a large number of research papers on the topic of fake profile detection across social networks. These works have contributed significantly to the field, both in terms of methods and results.

However, from the analysis of many of them, I noticed a common pattern.

Most of the papers I studied work under relatively limited settings:

they focus on one or two social platforms
they use one or two datasets
they test a small number of heuristics or optimization methods (if any)
and they usually rely on one or two data split strategies

In most cases, each study explores a specific and constrained configuration, but rarely the problem in a broader and more systematic way.

So the question that came to me was: What if we go further?

What if instead of evaluating models in a limited experimental setup, we try to build a more general and experimental system, that:

works across multiple social platforms
uses multiple datasets
explores multiple metaheuristic optimization strategies
tests different data splits
and provides a more rigorous and comparative benchmarking of models

Data & Sources

Research papers

I analysed 6 research papers on 3 main platforms:

Twitter (X now)
Facebook
Instagram

All of them expose labeled datasets created manually by researchers and use machine learning or deep learning methods. They also report performance scores, which allowed me to:

understand existing approaches
identify gaps and limitations
reuse datasets for fair comparison

Datasets

I worked on 5 datasets in total:

1 Facebook dataset
1 Twitter dataset
3 Instagram datasets

This multi-platform setup allowed me to evaluate how models behave across different social media environments and test their generalization ability.

All datasets were collected via platform APIs and manually labeled in the original studies.

Metaheuristic research papers

In addition to machine learning methods, I explored a wide range of metaheuristic optimization algorithms inspired by different real-world systems and games.

These algorithms are often designed as search strategies that simulate natural or social behaviors, such as competition, cooperation, or exploration.

I studied the following approaches:

Most Valuable Player Algorithm (MVPA)
Multi-Objective Volleyball Premier League (MOVPL)
Shell Game Optimization (SGO)
Tug of War Optimization (TWO)
Ring Toss Game Based Optimization
Puzzle Optimization Algorithm (POA)
Mixed Leader Based Optimizer (MLBO)
Soccer-Inspired Metaheuristics
Tiki-Taka Algorithm (TTA)
Running City Game Optimizer (RCGO)
Golf Optimization Algorithm (GOA)
Hide Objects Game Optimization (HOGO)
Football Game Based Optimization (FGBO)
Billiards-inspired Optimization Algorithm (BOA)
Kho-Kho Optimization Algorithm (KKO)
Orientation Search Algorithm (OSA)
Dice Game Optimizer (DGO)
Binary Orientation Search Algorithm (BOSA)

These methods may look very different on the surface, but they all share a common goal: explore a search space efficiently to find near-optimal solutions

Methodology Overview

Once the problem and data were clear, I designed the following pipeline to structure the entire system:

labeled input data is collected
data is cleaned
data is preprocessed
feature selection is applied
dataset is split into train/test (with different split strategies)
models are trained and tested
cross-validation is applied for more reliable evaluation
hyperparameter optimization is performed
best combination is selected:
- best features
- best algorithm
- best split strategy
final model is retrained using the best configuration
final model is deployed

[Labeled Data]
      |
      v
[Cleaning & Preprocessing]
      |
      v
[Feature Selection]
      |
      v
[Train / Test + Cross Validation + Splits]
      |
      v
[Model Benchmarking]
      |
      v
[Best Features + Best Model + Best Split]
      |
      v
[Final Retraining]
      |
      v
[Deployment (Hugging Face)]

System Implementation

Step 1: Generic Metaheuristic Engine

I started by implementing metaheuristic algorithms in a generic way, so I could reuse the same implementation for feature selection, scoring, and machine learning evaluation.

During this step, you don’t really feel the progress, since it takes a lot of time (more than a month in my case because of the number of algorithms). But once this foundation is done, the progress on the next steps becomes much faster and smoother.

Step 2: Data preprocessing and cleaning

I started working on this step in parallel with the first step in order to save time later in the process. The data preprocessing and cleaning phase was not identical for all datasets, as each one had its own structure, but in general it followed a common pipeline.

First, the usual preprocessing steps were applied, such as handling missing values and removing empty or irrelevant entries.

Then, for datasets containing raw profile names, I tried to extract as much useful information as possible. This included encoding the text and adding additional engineered features such as:

number of characters in the profile name
number of words in the profile name

The idea was that even simple textual patterns could carry useful signals for fake profile detection.

Finally, all features were normalized so that each attribute would have the same scale and contribute fairly to the learning process, avoiding bias toward features with larger numerical ranges.

Step 3: Feature selection

Variance Threshold (0.7)
SelectKBest
RFE (Recursive Feature Elimination)
Sequential Feature Selection
Mutual Information (MI) (combined with all implemented metaheuristics)
Gini Index (combined with all implemented metaheuristics)
Fisher Score (combined with all implemented metaheuristics)

In addition to these classical feature selection methods, I also integrated metaheuristic optimization techniques into the feature selection process.

The main idea was to go beyond standard deterministic selection methods and explore the feature space in a more flexible and intelligent way, allowing the model to discover feature combinations that traditional approaches might miss.

To make this exploration efficient and controlled, I designed a custom stopping strategy:

The optimization is executed in blocks of 100 iterations
After each block, I keep the best solution found so far
Then I launch the next block of 100 iterations

Now comes the stopping logic:

If the solution does not improve for 3 consecutive blocks, the process stops and the best solution is kept
Otherwise, it continues until a maximum of 10 blocks, after which the best overall solution is selected

In short, this acts as a controlled exploration mechanism: the algorithm is given multiple opportunities to improve, but it is stopped early when it clearly starts to stagnate, avoiding unnecessary computation while preserving performance.

Step 4: Machine Learning

Step 4.1: Algorithms

I started this step by identifying the most performing algorithms for each dataset.

The idea was simple: before applying feature selection and optimization, I wanted to evaluate all models using the full feature space. This allowed me to understand which algorithms naturally perform better depending on the dataset, so I could later combine the strongest models with the most relevant features.

At the same time, I explored different hyperparameter configurations for each algorithm to ensure a fair and robust comparison.

Random forest

n_estimators
max_depth
min_samples_split
min_samples_leaf
criterion
max_features

Logistic regression

C
penalty
solver
class_weight
max_iter

Naive bayes

alpha
fit_prior
class_prior

Linear SVC

C
penalty
loss
dual
tol
class_weight
max_iter

XGBoost

max_depth
learning_rate
n_estimators
subsample
colsample_bytree
scale_pos_weight

Deep Forest (Cascade forest)

n_estimators
max_depth
min_samples_split
min_samples_leaf

This initial benchmarking step helped me identify strong baseline models, which were later refined through feature selection and optimization.

Step 4.2: Splits

We often encounter the famous 80/20 split, where 80% of the data is used for training and 20% for testing. But how can we be sure that this split is the most optimal one?

I decided to go deeper and test multiple splits, almost like a detective: I tried 50/50, 60/40, 70/30, the classic 80/20, and finally 90/10.

Is there a difference? Yes, they tend to give different results. Is 80/20 always the most optimal one?
The answer is not always, as we will see in the results section just a bit later.

Step 4.3: Validation Strategy

To make the evaluation more reliable, I used cross-validation.

The idea is simple. Let’s take the example of an 80/20 split:

Instead of doing a single split (80% training / 20% testing)
The dataset is divided into multiple parts (folds)

For example, with 5-fold cross-validation:

The dataset is split into 5 equal parts
At each iteration:
- 4 parts (≈80%) are used for training
- 1 part (≈20%) is used for testing
This process is repeated 5 times, each time changing the test part

So every sample:

is used for training multiple times
is used for testing at least once

How is the data divided?

The data is divided into k equal subsets, called folds.

let's take the example of 5 folds

Fold 1 → Test | Train Train Train Train  
Fold 2 → Train | Test Train Train Train  
Fold 3 → Train | Train | Test Train Train  
Fold 4 → Train | Train Train | Test Train  
Fold 5 → Train | Train Train Train | Test

Why I did this step

At first, it might look like an unnecessary step.
Why not just split the data once and train/test directly?

The problem is that a single split can be biased. Some samples may be easier or harder than others, which can lead to misleading results.

With cross-validation:

the model is evaluated on different subsets of the data
the results become more stable and reliable
and the evaluation better reflects the model’s ability to generalize

In other words, instead of depending on one “lucky” split, this approach gives a more robust estimation of performance across the entire dataset.

Step 4.4: Metrics & Evaluation Strategy

What are all the metrics i recorded To evaluate model performance, I recorded a wide range of metrics for two main reasons:

To ensure that everything was working correctly (no missing steps, no overfitting, and stable training behavior)
To guarantee a fair comparison with other research papers, since not all of them report the same metrics—even though I focused my optimization on precision

The metrics I recorded were:

Accuracy
Precision (precision_score)
Recall (recall_score)
F1-score (f1_score)
Cohen’s Kappa (cohen_kappa_score)
Balanced Accuracy (balanced_accuracy_score)
Confusion Matrix
Best Hyperparameters
Training Time (s)
Testing Time (s)
Validation Time (s)

This combination allowed me to evaluate the models from multiple perspectives: performance quality, robustness, and computational cost.

Why precision

At first glance, one might ask: why choose precision instead of accuracy or F1-score? After all, accuracy gives a global view of performance, and F1-score balances precision and recall.

However, in the context of fake profile detection, the cost of errors is not symmetric.

If a fake profile is classified as real, the consequences can be serious:

users may trust malicious accounts
misinformation can spread more easily
in some cases (e-commerce, social engineering), it can lead to real harm

This is why precision becomes the most critical metric in this context. It directly measures how many predicted “real profiles” are actually real. In other words, the higher the precision, the fewer fake profiles are incorrectly labeled as trustworthy.

So instead of optimizing for general correctness, I focused on minimizing this specific and risky type of error.

Step 4.5: Hyperparameter Optimization

I experimented with several optimization approaches, including well-known ones such as:

Grid Search
Randomized Search
Bayesian Optimization

But I didn’t stop there. I also used metaheuristics with a custom stopping condition (the one we explained in the feature selection).

A brief recap of it's details:

I run the optimization in blocks of 100 iterations
After each block, I keep the best solution found
Then I launch another block of 100 iterations

Now comes the stopping logic:

If the solution does not improve for 3 consecutive blocks, I stop and keep the best result
Otherwise, I continue until I reach a maximum of 10 blocks, and then select the best solution overall

So in short, it’s like a controlled exploration: I give the algorithm multiple chances to improve, but I stop early if it clearly stagnates.

The stopping condition was based on precision not improving we just explained the why above.

Step 4.6: Recap

so here is the recap of all the training part

                    ┌────────────────────────────┐
                    │   Full Feature Dataset     │
                    └─────────────┬──────────────┘
                                  │
                                  v
                    ┌────────────────────────────┐
                    │  Model Benchmarking        │
                    │  (Multiple Algorithms)     │
                    │  RF / LR / SVC / XGB / NB  │
                    │  Deep Forest               │
                    └─────────────┬──────────────┘
                                  │
                                  v
                    ┌────────────────────────────┐
                    │ Hyperparameter Tuning      │
                    │ (Grid / Random / Bayesian  │
                    │ + Metaheuristics)          │
                    └─────────────┬──────────────┘
                                  │
                                  v
                    ┌────────────────────────────┐
                    │ Evaluation Strategy        │
                    │ - Train/Test Splits        │
                    │ - Multiple split ratios    │
                    │ - Cross Validation (k-fold)│
                    └─────────────┬──────────────┘
                                  │
                                  v
                    ┌────────────────────────────┐
                    │ Metrics Computation        │
                    │ Acc / Prec / Rec / F1      │
                    │ Kappa / Balanced Acc       │
                    │ Confusion Matrix           │
                    │ Time metrics               │
                    └─────────────┬──────────────┘
                                  │
                                  v
                    ┌────────────────────────────┐
                    │ Best Model Selection       │
                    │ + Best Hyperparameters     │
                    │ + Best Split Strategy      │
                    └────────────────────────────┘

Step 5: Feature scoring

You might ask the question: if I tested many approaches, did I use all of them for the final selection?

The answer is no. But then how did I get the final best feature set?

I followed a simple approach: I scored the features. At the beginning, all features have a score of 0. Every time a feature is selected by an algorithm, its score is incremented by 1.

At the end of all iterations, each feature has a final score. I simply sorted the features based on this score, and I got the overall best feature set.

Step 6: Retraining with the best feature and best algorithm

Now that I had identified both the best feature set and the best performing algorithm, the next step was to combine them into a final optimized model.

To build the most efficient version of the system, I retrained the model using only the top-ranked features, selected through the scoring method. In my case, I chose the top 5 features, which allowed me to reduce complexity while keeping strong predictive power.

Then, I retrained the best-performing algorithm using this reduced feature set. This step was important because it:

ensures the model is trained only on the most informative signals
reduces noise coming from less relevant features
improves generalization and stability
makes the final model lighter and faster to evaluate

As a result, I obtained a final model that is not only high-performing, but also simpler and easier to test and deploy in practice.

Results

Dataset	Accuracy	Precision	F1-score
Facebook	0.9880	0.9953	0.9953
Twitter	0.9200	0.9078	0.9212
Instagram (Dataset 1)	0.9378	0.9706	0.9333
Instagram (Dataset 2)	0.9378	0.9381	0.9333
Instagram (Dataset 3)	0.9880	0.9953	0.9953

Discussion

For sure, the “everything law” still doesn’t exist, as well as a universal best model in machine learning. However, I noticed some patterns in social media labeled datasets: tree-based algorithms often give the best results (like XGBoost and Random Forest), and in many cases, grid search is one of the most reliable methods for hyperparameter optimization.

Deployment

I deployed the final model on Hugging Face, choosing the best-performing version trained with the full feature set (I deployed the best of each platform which means one for facebook, one for X and one for Instagram).

The goal of this step was to make the model accessible and easy to test in a real-world setting, without requiring any local setup or complex dependencies.

By deploying the complete model (with all features), I ensured that:

no information loss occurs due to feature reduction
users can directly test realistic predictions
the pipeline remains consistent from training to deployment

This step marked the transition from a research-oriented system to a usable and interactive machine learning application.

Improvements for Future Work

I initially created separate Google Colab notebooks for each dataset, which led to some code repetition. I started with one dataset and then replicated the workflow for the others. In hindsight, I would design a shared module from the beginning to make the process more scalable and reusable.
I also started the experiments on Google Colab, but long training times and occasional disconnections made it less convenient. I later moved to a local Jupyter Notebook setup, and if I were to redo it, I would start directly with a local environment and GitHub for better version control and stability.

Conclusion

This project investigated fake profile detection across Facebook, Twitter, and Instagram using a full experimental machine learning pipeline. It combined multiple datasets, several classification algorithms, diverse feature selection techniques, and different optimization strategies to evaluate model performance in a systematic and comparable way.

A wide range of metrics was used, with a particular focus on precision due to the high cost of false positives in real-world scenarios. Cross-validation and multiple train/test splits were applied to ensure robust and reliable evaluation across datasets.

The results show that well-tuned ensemble methods such as Random Forest and Gradient Boosting achieve strong performance across platforms (in 4 out of 5 datasets). Metaheuristic-based feature selection sometimes provided some improvements, but did not consistently outperform classical methods (in 3 of the 5 datasets we tried the classical methods outperformed and were less time consuming), highlighting that sometimes simple strategies give better results.

Overall, this work demonstrates that robust fake profile detection can be effectively achieved through a well-designed classical ML pipeline combined with rigorous experimental evaluation across multiple datasets.

What Really Happens When You Run JavaScript Code

Thu, 23 Apr 2026 00:00:00 GMT

Introduction

You think you know JavaScript… but can you explain why setTimeout doesn’t always run when you expect?

The answer is in how JavaScript schedules and executes tasks. But how does it actually work?

To understand this, we need to talk about the event loop, what it is and how it works behind the scenes.

What is the Call Stack?

The event loop is a runtime mechanism that allows JavaScript to decide which task to execute next.

Before understanding it, you need to know that JavaScript is:

Single-threaded (it runs on a single main thread)
Non-blocking (it can handle asynchronous operations without stopping execution)

So how does the event loop manage this single thread and decide which task to execute next without blocking the execution?

We first need to look at the call stack, which, as the name implies, is a stack that handles all function calls in JavaScript. Let’s take a look at this code to understand how it works.

function first(){
	console.log("I'm first function");
	second()
}
function second(){
	console.log("I'm second function");
	third()
}
function third(){
	console.log("I'm third function");
	fourth()
}
function fourth(){
	console.log("I'm forth function");
}
fourth()

The call stack tries to execute code in a strict order, line by line.
It starts by encountering the call to first(). At this point, first() is pushed onto the stack and executed.

Inside first(), there is a call to second(), so second() is pushed on top of the stack and executed next.
Then second() calls third(), which is also pushed onto the stack.
Finally, third() calls fourth(), which is pushed last and executed at the top of the stack.

At the moment when fourth() is being executed, the stack looks like:

fourth()  
third()  
second()  
first()

Then execution happens from the top of the stack. fourth() executes first and is removed from the stack, then control returns to third(), followed by second(), and finally first().

But it still doesn’t explain something important: why doesn’t setTimeout always run when we expect it?

Understanding Async Execution

To understand that, we need to step outside the call stack and look at how JavaScript handles asynchronous tasks.

There is a task queue, which is where asynchronous tasks are stored once they are ready to be executed. It is essentially a waiting line of callbacks that will be processed later.

However, these tasks are not executed immediately. Even if a task is ready, it must wait until the call stack is empty before it can be processed. This is because JavaScript always executes synchronous code first.

This is what makes JavaScript non-blocking in practice.

How `setTimeout` Really Works

To better understand how the task queue and the call stack work together, let’s look at the following example and try to predict its output:

function  prepareDinner() {  
	setTimeout(() => {  
		console.log("I'm here");  
	}, 0);
  
	console.log("Starting dinner preparation");  
		cookFood();  
}  
  
function  cookFood() {  
	console.log("Cooking food");  
	serveFood();  
}  
  
function  serveFood() {  
	console.log("Serving food");  
}  
  
prepareDinner();

At first glance, you might think the output will be:

I'm here
Starting dinner preparation
Cooking food  
Serving food

But the actual output is:

Starting dinner preparation
Cooking food  
Serving food 
I'm here

So why does this happen, even though the delay is set to 0?

As we said before, JavaScript executes synchronous code first, which is pushed directly to the call stack.
Asynchronous code, like setTimeout, is handled separately and its callback is pushed to the task queue.

JavaScript will only execute tasks from the queue after finishing all the code in the call stack.

So even if setTimeout is set to 0, it doesn’t run immediately. It just means that the callback will be pushed to the task queue after 0ms, that’s all.

For example, if you set a setTimeout with a delay of 1s, the callback will be pushed to the task queue after 1 second.

But it may take more than 1 second to actually execute, because it still has to wait for the call stack to become empty.

There is one more important thing in the event loop that we didn’t introduce yet.

You might think that all asynchronous tasks are the same, and that all of them simply wait for the call stack to be empty before being executed, right?

There is another queue with higher priority than the task queue (which we can refer to as the macrotask queue, where setTimeout callbacks are placed).

This higher-priority queue is called the microtask queue.

This is where Promise.then callbacks are executed.

Microtasks have higher priority than the macrotask queue (like setTimeout), but they do not run before the call stack.

Instead, once the call stack becomes empty, JavaScript will execute all microtasks first, before moving to macrotasks.

Let's take a look at this code to understand better:

function prepareDinner() {
  setTimeout(() => {
    console.log("I'm here");
  }, 0);

  Promise.resolve().then(() => {
    console.log("Promise resolved");
  });

  console.log("Starting dinner preparation");
  cookFood();
}

function cookFood() {
  console.log("Cooking food");
  serveFood();
}

function serveFood() {
  console.log("Serving food");
}

prepareDinner();

So at the moment prepareDinner() starts executing:

The call stack contains:

serveFood
cookFood  
prepareDinner

The macrotask queue contains:

setTimeout callback

The microtask queue contains:

Promise callback

We said that the sync code in the call stack executes first so the output of it will be

Starting dinner preparation  
Cooking food    
Serving food

then the microtask right after when the call stack gets empty

Promise resolved

the macrotask gets executed only when the call stack is empty and all microtasks have already been executed

I'm here

The final output will be:

Starting dinner preparation  
Cooking food    
Serving food  
Promise resolved
I'm here

Web APIs and JavaScript Environment

We said that setTimeout is async code that gets pushed to the macrotask queue, and that is true, but there is something missing here.

setTimeout(), like fetch, and addEventListener, are external APIs provided by the browser (or by Node.js in backend environments). They are not part of JavaScript itself.

JavaScript only provides the execution engine (call stack + event loop model), but these APIs are provided by the environment.

For example, setTimeout does not get pushed directly to the macrotask queue.

When setTimeout is called, it first goes to the Web APIs, where the timer starts counting.

Only after the timer finishes does the callback get pushed to the macrotask queue, waiting for its turn to be executed.

Then, the event loop will pick it only when the call stack is empty and after all microtasks are finished.

Conclusion

Now you can explain with much more confidence why setTimeout does not guarantee execution immediately after the time has finished.

The reason is that setTimeout is not executed directly by JavaScript. Even when the timer is done, the callback still has to wait in the task queue until the call stack is empty and all microtasks are completed.

Only then does the event loop pick it up and push it to the call stack for execution.

That’s why the delay in setTimeout is not an exact execution time, but only a minimum waiting time before it becomes eligible to run.

Hope you enjoyed this article. Feel free to explore more posts to keep learning.

Setting Up TurboRepo Is Easy… Until You Add Another App

Sun, 19 Apr 2026 00:00:00 GMT

Introduction

Setting up a monorepo is usually a straightforward task, you just run this command:

pnpm dlx create-turbo@latest

and you think you are done, right ?

The setup feels complete as soon as the command finishes, but in practice, that’s rarely the case.

The command generates a ready-to-use boilerplate with this structure:


apps/
  ├── web/
  ├── docs/
packages/
  ├── ui/
  ├── config/
turbo.json
package.json

At this stage, you simply install the dependencies, and you already have a working Next.js web application along with a ready-to-use Next.js documentation app.

But what if you want to add another application to this structure?

Here I will focus on two cases, but the same approach applies to any framework or library you might want to add: NestJS and Django.

Adding a New Application

First you navigate to apps folder:

cd apps

Then you install your application in the usual way:

for Nest.js

pnpm dlx @nestjs/cli new api

for Django

django-admin startproject api

Then you continue by installing the required dependencies for each application. Everything is fine till now, right ?

The First Issue: Application Not Running

However, once you navigate back to the root of your monorepo and try to run everything:

cd ../..
pnpm dev

only the web and documentation applications start, but why ?`

Understanding the Problem

TurboRepo doesn’t “discover” how to start each application automatically, it look for a specific script in each application, this script is "dev".

You can take a look to the turborepo package.json file and confirm that:

{
	"name": "...",
	"private": true,
	"scripts": {
		"build": "turbo run build",
		"dev": "turbo run dev",
		"lint": "turbo run lint",
		"format": "prettier --write \"**/*.{ts,tsx,md}\"",
		"check-types": "turbo run check-types"
	},
	"devDependencies": {
		...
	},
	...
}

However in the Nest.js case you have this:

{
	"scripts": {
		...
		"start:dev": "nest start --watch",
		...
	},
	...
}

Renaming start:dev to dev allows the monorepo to pick up the application. However, when running it, the service crashes — revealing another issue.

The Second Issue: Port Conflict

The root cause is a port conflict.

By default, both the Next.js application and the NestJS server attempt to run on the same port. As a result, it fails to start.

The solution is straightforward: assign a different port to one of the services.

For example, you can update the NestJS application to run on port 4000:

	await app.listen(process.env.PORT  ??  4000);

Now that the NestJS case is resolved, what about the Django application, which doesn’t belong to the JavaScript ecosystem?

Integrating Django

Unlike NestJS, Django doesn’t rely on a package.json, so TurboRepo has no direct way to detect or run it.

To integrate it into the monorepo workflow, you need to explicitly define how it should be executed.

One practical approach is to add a minimal package.json inside the Django application directory and expose a dev script:

{
    "name": "api",
    "scripts": {
      "dev": "python manage.py runserver 0.0.0.0:8000",
      "migrate": "python manage.py migrate",
      ...
    }
}

This allows TurboRepo to treat the Django app like any other workspace and include it when running, also as before, make sure the Django server runs on a different port to avoid conflicts with other services.

Conclusion

Setting up a monorepo is fast, but integrating multiple applications into the workflow requires more attention.

Whether you’re working with JavaScript frameworks like NestJS or external ecosystems like Django, the key is to make every application conform to the unified interface.

And now you can enjoy your monorepo.

Houda Debza

Introduction au JavaScript : Au-delà du langage interprété

Introduction

Donc en réalité, c'est quoi JavaScript ?

JIT (Just In Time Compilation)

Interpréteur

Compilateur

JIT

Types dynamiques

Multi-paradigme

Programmation procédurale

Programmation orientée objet

Programmation fonctionnelle

Unique Thread

Garbage Collected

Récap en carte mentale

Histoire de JavaScript

Conclusion

NestJS JWT Auth with Email Verification

Introduction

What are we going to do

Setting up the environment

Create The Database module and the user schema

Initiating the Database

Creating the database module

Creating the database Schema

Authentication module

Email verification

Install the dependencies

Getting an API key

Email module

Email verification, auth service

Test the email verification

Conclusion

Cross-Platform Fake Profile Detection: Experimental Machine Learning Graduation Project

Introduction

Table of Contents

The journey

The Problem I Tried to solve

Data & Sources

Research papers

Datasets

Metaheuristic research papers

Methodology Overview

System Implementation

Step 1: Generic Metaheuristic Engine

Step 2: Data preprocessing and cleaning

Step 3: Feature selection

Step 4: Machine Learning

Step 4.1: Algorithms

Step 4.2: Splits

Step 4.3: Validation Strategy

How is the data divided?

Why I did this step

Step 4.4: Metrics & Evaluation Strategy

Step 4.5: Hyperparameter Optimization

Step 4.6: Recap

Step 5: Feature scoring

Step 6: Retraining with the best feature and best algorithm

Results

Discussion

Deployment

Improvements for Future Work

Conclusion

What Really Happens When You Run JavaScript Code

Introduction

What is the Call Stack?

Understanding Async Execution

How setTimeout Really Works

Web APIs and JavaScript Environment

Conclusion

Setting Up TurboRepo Is Easy… Until You Add Another App

Introduction

Adding a New Application

The First Issue: Application Not Running

Understanding the Problem

The Second Issue: Port Conflict

Integrating Django

Conclusion

How `setTimeout` Really Works