https://cegepmv.github.io/420-412/index.htmlLe présent cours vise à amener la personne étudiante à concevoir, développer et déployer une application Web complète, en s’appuyant sur des cadriciels modernes et sur une méthodologie de développement structurée. Réalisé sous forme de projet s’échelonnant sur l’ensemble de la session, ce cours met l’accent sur la mise en pratique concrète des notions vues dans les cours précédents, tout en plaçant la personne étudiante dans un contexte réaliste de développement logiciel.Hugofr-frhttps://cegepmv.github.io/420-412/fondations-app-web/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://cegepmv.github.io/420-412/fondations-app-web/index.htmldéveloppement d’applications Web Le développement d’une application Web moderne repose sur une combinaison de concepts, d’outils et de choix architecturaux qui permettent de concevoir des systèmes fiables, évolutifs et maintenables. Avant d’entrer dans l’implémentation concrète d’un projet, il est essentiel de comprendre comment une application Web est structurée, comment ses différentes couches interagissent et pourquoi certaines technologies sont privilégiées. Cette page présente les fondements nécessaires à la compréhension et à la mise en œuvre d’un projet de développement Web moderne. Elle aborde l’architecture générale d’une application transactionnelle et les principes qui la sous-tendent, notamment la séparation claire des responsabilités entre le client, le serveur, l’API et la base de données, ainsi qu’un aperçu des technologies et du stack utilisés dans le cadre de ce cours, lesquels serviront de base au projet à réaliser.https://cegepmv.github.io/420-412/01-arch-nest/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://cegepmv.github.io/420-412/01-arch-nest/index.htmlNestJS repose sur une architecture modulaire inspirée de concepts issus de frameworks comme Angular. Elle structure les applications backend autour de modules, contrôleurs et services, tout en intégrant un pipeline de traitement des requêtes HTTP. Comprendre ce pipeline est essentiel pour savoir où placer la validation, la sécurité, la logique métier et la transformation des réponses. Image tableau en class.https://cegepmv.github.io/420-412/02-api-http/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://cegepmv.github.io/420-412/02-api-http/index.htmlCette page résume les différentes sections d’une requête HTTP et la récupération des données dans NestJS avec @Param(), @Query() et @Body().https://cegepmv.github.io/420-412/03-validation-pipe/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://cegepmv.github.io/420-412/03-validation-pipe/index.htmlLes Validation Pipes permettent de valider automatiquement les données entrantes (ex. body, query, params) avant qu’elles n’atteignent la logique métier. L’objectif est d’éviter de traiter des données incomplètes, mal typées ou contenant des propriétés non prévues. Étapes essentielles (4 étapes) 1) Activer la validation globale dans main.ts L’activation globale applique la validation à toutes les requêtes qui utilisent des DTO (objets de transfert de données). import { ValidationPipe } from '@nestjs/common'; import { NestFactory } from '@nestjs/core'; import { AppModule } from './app.module'; async function bootstrap() { const app = await NestFactory.create(AppModule); app.useGlobalPipes( new ValidationPipe({ whitelist: true, // supprime les propriétés non définies dans le DTO forbidNonWhitelisted: true, // retourne une erreur si des propriétés inconnues sont envoyées transform: true, // transforme le payload en instance du DTO }), ); await app.listen(3000); } bootstrap(); Notes pédagogiques :https://cegepmv.github.io/420-412/04-dependency-injection/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://cegepmv.github.io/420-412/04-dependency-injection/index.htmlDependency Injection (NestJS) La Dependency Injection (DI) est un principe fondamental de NestJS. Elle permet d’injecter automatiquement des dépendances (ex. services, repositories) dans d’autres classes (ex. contrôleurs) sans les instancier manuellement avec new. L’objectif est de : séparer les responsabilités, faciliter les tests, réduire le couplage entre les classes, centraliser la gestion des dépendances dans les modules. Injection de dépendance dans un module Étape 1 : décorer le service avec @Injectable() Un service doit être injectable pour pouvoir être utilisé ailleurs.https://cegepmv.github.io/420-412/design-api/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://cegepmv.github.io/420-412/design-api/index.htmlGestion des utilisateurs Cette section décrit les routes principales liées à l’authentification dans le module User, ainsi que l’organisation interne du module (Controller, Service, Repository). Les routes d’authentification sont regroupées sous le préfixe /auth. Méthode Route Entrée (Body / Query / Params) Description POST /auth/signup Body: {email, password, (optionnel: name, age, etc.)} Crée un nouvel utilisateur, valide les données, chiffre le mot de passe et enregistre en base de données. POST /auth/signin Body: {email, password} Authentifie un utilisateur existant, vérifie le mot de passe et retourne une réponse d’authentification. signup → création d’un nouvel utilisateur (écriture en base). signin → vérification des informations d’identification. Le contrôleur reçoit les données (@Body()), les services traitent la logique métier, et le repository gère l’accès à la base de données (SQLite pour le moment). Organisation interne du module Users Le module Users regroupe plusieurs composants. On distingue, dans ce projet, deux services :https://cegepmv.github.io/420-412/typeorm/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://cegepmv.github.io/420-412/typeorm/index.htmlTypeORM fournit un ensemble de méthodes standardisées pour gérer les opérations CRUD. La documentation officielle : Repository API : https://typeorm.io/docs/working-with-entity-manager/repository-api/ Working with Repository (NestJs) : https://docs.nestjs.com/techniques/database Les méthodes principales Lecture find() → retourne une liste d’entités findOneBy(criteria) → retourne une entité selon un critère Création create(data) → crée une instance sans sauvegarder en base save(entity) → sauvegarde en base (insert ou update) Mise à jour update(criteria, partialEntity) → met à jour sans charger l’entité complète Suppression remove(entity) → supprime une entité existante delete(criteria) → supprime directement via un critère La différence entre create() et save() repository.create()https://cegepmv.github.io/420-412/authentication/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://cegepmv.github.io/420-412/authentication/index.htmlL’authentification permet d’identifier un utilisateur et de s’assurer qu’il est bien celui qu’il prétend être. Nous utilisons, dans notre application, un mécanisme basé sur les cookies pour maintenir la session entre le client (navigateur) et le serveur. Vue globale du flow d’authentification Le processus se déroule en plusieurs étapes : 1. Inscription / Connexion Le client envoie une requête HTTP : POST /auth/signup { email, password } Le serveur : Vérifie si l’email existe déjà Chiffre le mot de passe Enregistre l’utilisateur en base de données 2. Génération du cookie Une fois l’utilisateur créé ou authentifié, le serveur :https://cegepmv.github.io/420-412/06-interceptor-serialization/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://cegepmv.github.io/420-412/06-interceptor-serialization/index.htmlAu départ, la route whoAmI dans UsersController fonctionnait ainsi : Le contrôleur reçoit la requête Il appelle une méthode du AuthService Le service lit le cookie / la session pour récupérer un userId Le service retrouve l’utilisateur correspondant Le problème pédagogique/architectural : Le contrôleur “sait trop” comment on retrouve l’utilisateur On répète la même logique dans plusieurs routes On mélange la logique “transversale” (retrouver l’utilisateur courant) avec la logique d’une route Objectif : éviter de répéter et rendre l’accès à l’utilisateur courant automatique.https://cegepmv.github.io/420-412/07-guards/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://cegepmv.github.io/420-412/07-guards/index.htmlActuellement dans notre application, nous avons déjà mis en place : un décorateur @CurrentUser() un CurrentUserInterceptor Cependant, lorsque nous voulons créer un Guard pour bloquer certaines routes, nous rencontrons un problème. Nous voudrions écrire un guard qui vérifie : si req.currentUser existe sinon bloquer l’accès Helas, cela ne fonctionne pas. L’ordre d’exécution dans NestJS est : Middleware ↓ Guard ↓ Interceptor ↓ Controller Donc : le Guard s’exécute avant l’Interceptor req.currentUser n’existe pas encore le Guard ne peut donc pas vérifier l’utilisateur La solution : utiliser un Middleware Pour résoudre ce problème, nous allons déplacer la logique qui trouve l’utilisateur dans un middleware.https://cegepmv.github.io/420-412/11-react-router/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://cegepmv.github.io/420-412/11-react-router/index.htmlCette section a pour objectif de transformer votre manière de concevoir une application React en créant une connexion fluide et robuste entre votre interface et votre API NestJS. Nous allons partir des fondements acquis dans le cours 420-211 - Applications Web pour pousser les concepts un peu plus loin. Pour mettre cela en pratique, nous allons travailler sur une application concrète. Nous utiliserons un projet frontend de départ contenant des données “en dur”(mock data) ainsi qu’un backend déjà fonctionnel :https://cegepmv.github.io/420-412/typescript/index.htmlMon, 01 Jan 0001 00:00:00 +0000https://cegepmv.github.io/420-412/typescript/index.htmlTypeScript est un surensemble de JavaScript qui ajoute un système de types statiques au langage. Autrement dit, tout code JavaScript valide est également du code TypeScript, auquel peuvent s’ajouter des annotations de types visant à améliorer la lisibilité, la robustesse et la maintenabilité du code. TypeScript = JavaScript + un système de types