dans Programmation 101
À la découverte de Nest
Lorsqu’on nous vend Node comme backend, on nous dit : « Tu vas avoir un seul langage sur toute ta stack! ». L’idée est vraiment intéressante pour certains devs, car plusieurs d’entre vous ont une aversion inébranlable envers le DotNet 😛 Aujourd’hui, je vous présente un framework Node tout spécial que je surveille depuis ses débuts, soit Nest.
Présentation
Nest nous promet une chose : notre code backend va ressembler à notre code frontend parce qu’il supporte TypeScript par défaut. Ceci dit, c’est en supposant que vous utilisez du JS pour le frontend et le backend. La raison pour laquelle je vous présente ce framework aujourd’hui est simple et correspond à mes conseils sur le choix d’une techno dans un projet de production :
- Des compagnies l’utilisent en production
- Elle a été testée dans des cas réel
- Il y a un nombre raisonnable de bogues dans GitHub
- Il y a un nom raisonnable d’étoiles dans GitHub
- L’historique de commit démontre l’activité de la techno
Pourquoi choisir Nest
Le framework est, comme les auteurs le disent, grandement inspiré d’Angular. Si votre frontend est fait avec ce dernier, Nest devient un choix plus qu’intéressant à cause de sa syntaxe qui ressemble à celle d’Angular.
De plus, Nest possède tous les outils nécessaires à la création d’applications complètes, comme des intercepteurs, middlewares, injection de dépendances, etc..
Nest-cli
Tout comme Angular, Nest nous propose une interface console pour générer du code. commençons donc un nouveau projet :
|
1 2 3 4 |
npm install -g @nestjs/cli nest new nom-du-projet cd nom-du-projet npm run start |
Donc, en premier, on installe le cli globalement, puis on crée le projet et on l’exécute. Vous devriez voir Hello World si vous atteignez la page d’accueil.
Structure du projet
Nest-cli va créer une structure de répertoires semblable à celle d’Angular. Le premier fichier qui nous intéresse, c’est app.module.ts :
|
1 2 3 4 5 6 7 8 |
@Module({ imports: [], controllers: [AppController], providers: [AppService], }) export class AppModule { } |
Ça vous rappelle quelque chose? Donc, vous l’aurez deviné, tous nos contrôleurs vont être déclarés dans l’annotation Module sous la propriété controllers, et les providers vont nous servir à déclarer les services et autres types injectables.
Un premier contrôleur
Pour démontrer le principe de routage, créons un nouveau contrôleur via le cli :
|
1 |
nest g controller time |
Le cli va nous créer un contrôleur en TypeScript, sa classe de tests unitaires et va aussi ajouter la référence au module. Modifions le code TS pour le suivant :
|
1 2 3 4 5 6 7 8 9 10 |
@Controller('time') export class TimeController { constructor() {} @Get('getTime') getTime(): Date { return new Date(); } } |
Avec le paramètre de l’annotation Controller, on définit la base de la route. Ici, ce sera domain.com/time. Puis, avec les annotations Get, Post, Put ou Delete, on ajouter la méthode à la route, ici GET domain.com/time/getTime.
Injection de dépendances
Créons d’abord un service avec nest-cli :
|
1 |
nest g service time |
Puis ajoutons le code suivant :
|
1 2 3 4 5 6 |
@Injectable() export class TimeService { getTime(): Date { return new Date(); } } |
Les programmeurs Angular verront assurément la ressemblance. En fait, la syntaxe est la même! Encore une fois, nest-cli nous a ajouté l’entrée dans les providers de AppModule.
Et pour l’injecter dans le contrôleur? Facile :
|
1 2 3 4 5 6 7 8 9 10 |
@Controller('time') export class TimeController { constructor(private readonly timeService: TimeService) {} @Get('getTime') getTime(): Date { return this.timeService.getTime(); } } |
Le conteneur d’injection de dépendances va s’occuper de gérer l’instance de TimeService.
Middlewares!
Dernier point et je vous laisse explorer, mais il est possible de créer tout aussi facilement des middlewares devant vos méthodes de contrôleur.
Créons le middleware :
|
1 |
nest g middleware auth |
Supposons un cas ou vous voulez valider un jeton de sécurité dans les entêtes http, vous pourriez le faire comme ceci :
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
@Injectable() export class AuthMiddleware implements NestMiddleware { use(req: Request, res: Response, next: () => void) { const token = req.headers['x-access-token']; if (!token) { console.log('Token not provided'); } else { console.log('OK!'); } next(); } } |
Puis, pour l’activer, ceci se fait en implémentant NestModule dans AppModule et en définissant la méthode configure() comme suit :
|
1 2 3 4 5 6 7 8 9 10 11 |
@Module({ imports: [], controllers: [AppController, TimeController], providers: [AppService, TimeService], }) export class AppModule implements NestModule { configure(consumer: MiddlewareConsumer) { consumer.apply(AuthMiddleware).forRoutes('*'); } } |
Conclusion
Aujourd’hui, je l’espère, vous avez découvert un nouveau framework. L’avantage indéniable de nest pour un backend à Angular en fait un choix à considérer dans une entreprise. Ça peut paraître évident comme ça, mais si le backend est dans une autre techno, admettons C#, il sera difficile, mais pas impossible, de trouver des programmeurs qui sont expert sur la stack au complet.
Ceci dit, vous le connaissiez? L’utilisez-vous? Je veux vos expériences dans les commentaires ci-dessous 🙂 Merci de partager cet article comme à chaque semaine dans vos réseaux respectifs.
Cheers!
Commentaires
Laisser un commentaire