# API Express JWT

API REST Node.js avec Express pour gérer l’authentification (login/register/profile) avec :

- JSON Web Token (JWT) pour l’authentification
- Rate limiting pour limiter les requêtes (global et login)
- Logs avec Winston (requêtes et erreurs)
- Swagger pour la documentation
- Fichier `users.json` comme base de données simple

---

## 🚀 Installation

1. Cloner le projet

```bash
git clone <repo-url>
cd express

2. Installer les dépendances

npm install

3. Créer le fichier .env à la racine

PORT=3000
JWT_SECRET=super_secret_token_123

4. Créer le dossier logs pour Winston

mkdir logs
touch logs/.gitkeep

⚙️ Scripts npm

npm start      # Lancer le serveur
npm run dev    # Lancer le serveur en mode développement avec nodemon

📂 Structure du projet

express/
├── src/
│   ├── app.js
│   ├── server.js
│   ├── routes/
│   │   └── v1/
│   │       └── auth.routes.js
│   ├── modules/
│   │   └── v1/
│   │       └── auth/
│   │           ├── auth.controller.js
│   │           └── auth.service.js
│   ├── middlewares/
│   │   ├── logger.middleware.js
│   │   ├── error.middleware.js
│   │   └── auth.middleware.js
│   └── config/
│       └── swagger.js
├── users.json
├── logs/
│   └── .gitkeep
├── package.json
└── .env

🔐 Auth / Endpoints

Register

POST /api/v1/auth/register
Content-Type: application/json
Body:
{
  "email": "[email protected]",
  "password": "123456"
}

Réponse :

{
  "email": "[email protected]",
  "password": "<hashed_password>"
}

Login

POST /api/v1/auth/login
Content-Type: application/json
Body:
{
  "email": "[email protected]",
  "password": "123456"
}

Réponse :

{
  "token": "<JWT_TOKEN>"
}

Limité à 5 tentatives toutes les 15 minutes par IP

Profile (JWT)

GET /api/v1/auth/profile
Headers:
Authorization: Bearer <JWT_TOKEN>

Réponse :

{
  "email": "[email protected]"
}

🛡️ Rate Limiting

• Global : 100 requêtes / IP / heure
• Login : 5 tentatives / IP / 15 minutes

📊 Logs avec Winston

• logs/api.log → toutes les requêtes (méthode, URL, body, query, headers)
• logs/errors.log → toutes les erreurs (stack, message, endpoint)

📖 Swagger Documentation

• URL : http://localhost:3000/api/docs
• Documentation interactive avec tous les endpoints et modèles JSON

⚡ Notes

• Le projet utilise un simple fichier users.json comme DB. Pour production, remplacer par une vraie base de données.
• .gitignore :

node_modules
.env
/logs/*
!/logs/.gitkeep

• Ne jamais committer les tokens ou mots de passe réels.

🛠️ Stack

• Node.js
• Express
• JSON Web Token (JWT)
• Bcrypt
• Morgan
• Winston
• express-rate-limit
• Swagger UI / swagger-jsdoc

👨‍💻 Développement

• Lancer en dev avec reload automatique :

npm run dev

• Logs en console + fichier
• Tester les endpoints avec Postman ou Swagger UI

---

## 🧩 Génération automatique de modules (CLI)

Ce projet fournit une **commande CLI interne** permettant de générer rapidement un module Express complet, inspiré de l’approche Symfony (`make:controller`, `make:entity`).

### 📦 Structure générée

La commande génère automatiquement un module versionné (`v1`) avec la structure suivante :

src/modules/v1// ├── .controller.js ├── .service.js ├── .model.js └── .routes.js

Chaque fichier est **pré-rempli** avec une base fonctionnelle (controller, service, model, routes).

---

### 🚀 Utilisation

```bash
npm run make:module <module-name>

Exemple

npm run make:module user

Résultat :

src/modules/v1/user/
├── user.controller.js
├── user.service.js
├── user.model.js
└── user.routes.js

🔗 Enregistrement automatique des routes

Lors de la génération d’un module :

• le fichier src/routes/v1/index.js est mis à jour automatiquement
• la route du module est enregistrée sans action manuelle

Exemple :

router.use('/user', userRoutes);

⚠️ Le fichier routes/v1/index.js contient des marqueurs spéciaux utilisés par le générateur :

// AUTO-IMPORTS (do not remove)
// AUTO-ROUTES (do not remove)

👉 Ne pas supprimer ces commentaires, ils permettent l’injection automatique.

🧠 Convention utilisée

• Architecture modulaire inspirée de Symfony

• Séparation claire :

  • controller → HTTP
  • service → logique métier
  • model → accès base de données
  • routes → définition des endpoints

• Versioning par dossier (v1, v2, …)

🛠️ Prérequis

• Node.js ≥ 18
• npm
• Le script CLI est défini dans scripts/make-module.js

🧪 Bonnes pratiques

• Modifier uniquement le code généré (pas le script)

• Un module = une responsabilité métier

• Les routes sont accessibles via :

  /api/v1/<module>

📌 Exemple d’URL finale

GET /api/v1/user

🛠️ CLI interne alexis

Ce projet fournit une CLI maison nommée alexis, inspirée des commandes Symfony (bin/console), afin de simplifier la génération de code et la gestion de la base de données.

La CLI encapsule TypeORM et les scripts internes du projet pour offrir une DX propre et homogène.

📦 Installation de la CLI

La commande alexis est disponible localement via npm.

Après installation des dépendances :

npm link

La commande devient accessible globalement :

alexis

ℹ️ En environnement CI ou sans lien global, les commandes peuvent aussi être lancées via :

npm run alexis <commande>

🚀 Commandes disponibles

➕ Générer une migration

alexis make migration <name>

Génère automatiquement une migration TypeORM (JavaScript) à partir des entités existantes.

Exemple :

alexis make migration create-user

➡️ Crée un fichier dans :

src/migrations/

🗄️ Appliquer les migrations

alexis migrate

Exécute toutes les migrations en attente sur la base de données.

Équivalent Symfony :

php bin/console doctrine:migrations:migrate

↩️ Annuler la dernière migration

alexis migrate rollback

Annule la dernière migration exécutée.

🧠 Fonctionnement interne

• La CLI appelle TypeORM via npx

• Les migrations sont générées en JavaScript (compatibles CommonJS)

• La configuration ORM est centralisée dans :

  src/config/orm.js

📁 Structure concernée

src/
├── entities/        # Entités (EntitySchema)
├── migrations/      # Migrations TypeORM
├── config/
│   └── orm.js       # Configuration ORM
└── modules/

⚠️ Notes importantes

• Ne pas éditer manuellement les migrations générées
• Toujours vérifier les migrations avant exécution en production
• Les décorateurs (@Entity) ne sont pas utilisés (JavaScript natif)

🧩 Philosophie

La CLI alexis vise à :

• offrir une expérience Symfony-like en Express
• standardiser la génération de code
• masquer les détails techniques (TypeORM, SQL)
• améliorer la maintenabilité du projet

🔐 Génération automatique du système d’authentification

Le projet fournit une commande dédiée pour générer un système d’authentification complet (JWT), inspiré de make:auth de Symfony.

🚀 Commande

alexis make auth

🧩 Ce que fait la commande

La commande alexis make auth génère automatiquement :

1️⃣ Entité utilisateur (si absente)

src/entities/User.entity.js

Avec les champs par défaut :

• id
• email (unique)
• password
• createdAt

2️⃣ Module auth

src/modules/v1/auth/
├── auth.controller.js
├── auth.service.js
└── auth.routes.js

Fonctionnalités incluses :

• POST /auth/register
• POST /auth/login
• GET /auth/profile
• Hash du mot de passe (bcrypt)
• JWT (jsonwebtoken)
• Swagger auto-généré

3️⃣ Middleware JWT

src/middlewares/auth.middleware.js

Permet de protéger les routes avec un token JWT via l’en-tête :

Authorization: Bearer <token>

4️⃣ Configuration JWT

src/config/jwt.js

module.exports = {
  JWT_SECRET: process.env.JWT_SECRET || 'change-me'
};

5️⃣ Enregistrement automatique des routes

La route /auth est automatiquement enregistrée dans :

src/routes/v1/index.js

Aucune modification manuelle n’est nécessaire.

🔄 Flow recommandé (équivalent Symfony)

alexis make auth
alexis make migration create-users
alexis migrate
npm start

🌐 Endpoints générés

| Méthode | URL | Description | | ------- | ----------------------- | ------------------------------- | | POST | /api/v1/auth/register | Création d’un utilisateur | | POST | /api/v1/auth/login | Connexion (JWT) | | GET | /api/v1/auth/profile | Profil utilisateur (JWT requis) |

📘 Swagger

Les endpoints d’authentification sont automatiquement documentés et visibles sur :

http://localhost:3000/api/docs

Fonctionnalités Swagger :

• Tags Auth
• Sécurité JWT (bearerAuth)
• Exemples de payloads

🧠 Notes d’architecture

• Le système d’authentification utilise TypeORM (pas de model.js)

• L’entité User est utilisée comme source unique de vérité

• Le pattern est :

  Controller → Service → Entity (Repository)

• Aucune table auth n’est créée (logique métier uniquement)

⚠️ Bonnes pratiques

• Changer JWT_SECRET en production
• Ne jamais exposer le champ password
• Ajouter un rate-limiter sur /auth/login en production
• Utiliser HTTPS pour le transport du token