Skip to content
Branch: master
Clone or download
Pull request Compare This branch is 6 commits ahead of AxaGuilDEv:master.
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
assets
demo
dist
footer
presentation
.babelrc
.eslintignore
.eslintrc
.gitignore
LICENSE
README.md
index.html
index.js
package-lock.json
package.json
server.js
webpack.config.js
webpack.config.production.js
yarn.lock

README.md

nestjs-talk

Talk about Nest Framework 🚀

Contents

Reference

The Spectacle core API is available at https://github.com/FormidableLabs/spectacle/blob/master/README.md.

Getting Started

First, install the dependencies by running

npm install

Then, to start up the local server, run

npm start

Open a browser and hit http://localhost:3000, and we are ready to roll.

Build

Building the dist version of the project is as easy as running

npm run build

Titre: Un zeste de Nest pour réhausser le goût du back-end JS

Synopsis

Nous connaissons tous un développeur frontend qui est devenu plus efficace grâce à des solutions comme Angular, Vue ou React. On connait également des développeurs backend qui développent de manière architecturée grâce à Spring Boot pour Java ou ASP.NET Core pour .NET Core. Et côté NodeJS ? 99% utilisent Express, qui est loin d'être un équivalent... Pourtant il y a plein d'intérets à proposer des facilitants qui permettraient en plus d'utiliser côté client comme serveur le même language de programmation, un environnement d'exécution proche, de partager du code commun, d'ajouter un contrôle statique du code à la compilation avec TypeScript... Et si NestJS était notre guide vers ce graal sans dénaturer le goût de liberté qu'on aime tant ? Venez découvrir cet ingrédient pour vous aider à faire mijoter vos projets !

Notes

Introduction

Constat

Beaucoup de frameworks et libs côté front-end ont permis aux développeurs d'être plus productifs, tout en construisant des applications plus volumineuses et élégantes, sans que leurs performances ne soient lésées.

Côté back-end avec NodeJS, les frameworks les plus utilisés ne proposent pas de solutions aux principaux besoins récurrents des développeurs, il faut piocher dans l'écosystème pour trouver son bonheur et quand des problèmes surviennent pour faire évoluer l'architecture, les développeurs se retrouvent seuls face à npm.

Il existe bien des frameworks comme loopback qui proposent de répondre aux besoins récurrents des développeurs mais leur approche et leur configuration peuvent faire peur et mener à la création d'usine à gaz magiques.

Problèmes rencontrés

  • des contrĂ´leurs de partout dans une arborescense de fichiers non normĂ©e
  • difficilement testable (extraction des callback dans des mĂ©thodes de classe dĂ©diĂ©e + utilisation async await) mais pas suffisant Ă  notre goĂ»t (toujours req, res, app...)
  • on confie tout aux middlewares (auth, logging, data transformation & validation, exception handlers...)
  • absence typage, couplage fort avec un framework particulier,

Heureusement, NestJS est arrivé !!!

NestJS

Présentation générale

  • Opinionated (cette-fois ci) et tirĂ© du monde d'Angular + Spring Boot (pour les adeptes, vous devriez reconnaĂ®tre un bon nombre de similitude ;))
  • BasĂ© sur Express
  • Ecrit en Typescript
  • SOLID principles
  • Propose une rĂ©elle architecture applicative et simplifie la mise en place du DDD
  • Finit le couplage fort Ă  Express (req, res, app) + mocking de ces objets dans les tests
  • Simples fonctions indĂ©pendantes de toute couche de transport (HTTP, Websocket) et facilement testables retournant val sync (promise) ou async (observable)

Très bien, voyons ce qu'apporte réellement Nest en terme de productivité, de maintenabilité, de testabilité et d'architecture...

Concepts

Controllers

  • DĂ©corateurs : @Controller, @Get() etc...
  • Codes de retour paramĂ©trables
  • RĂ©cupĂ©ration des objets req res via des dĂ©corateurs si besoin...

Providers

  • Presque tout est considĂ©rĂ© comme un provider (service, repo, facotry, helper etc...)
  • Ils peuvent tous ĂŞtre injectĂ©s dans des constructeurs
  • DĂ©corateur: @Injectable
  • Injection de dĂ©pendances (private readonly myService: MyService)

Modules

Middlewares

  • Fonction appelĂ© avant le route handler. Ils ont accès Ă  la requĂŞte, Ă  la rĂ©ponse et au prochain middleware (req, res, next)
  • implements NestMiddleware avec une fonction resolve qui retourne une MiddlewareFunction
  • TirĂ© de la doc d'express : "Middleware functions can perform the following tasks:"
    • execute any code.
    • make changes to the request and the response objects.
    • end the request-response cycle.
    • if the current middleware function does not end the request-response cycle, it must call next() to pass control to the next middleware function. Otherwise, the request will be left hanging.
  • Application des middlewares dans un module via la mĂ©thode configure(consumer: MiddlewareConsumer)

Exception filters

  • gestion des exceptions lancĂ©es par l'appli
  • finit les res.status(404).end() ni d'utilisation de boom, il y a des built-in classes NotFoundException, ForbiddenException etc... (throw new NotFoundException())
  • CrĂ©ation de ses propres exceptions Ă©galement en Ă©tendant HttpException
  • ces filtres sont Ă©xĂ©cutĂ©s en fin de chaĂ®ne pour le type d'exception qu'on leur attribue (si aucun spĂ©cifiĂ© => pour toutes les exceptions de l'appli)
  • DĂ©corateur @Catch(NotFoundException)
  • Class qui implĂ©mente Exceptionfilter avec une mĂ©thode catch(exception: HttpException, host: ArgumentsHost)
  • Utile pour logger dès lors qu'une exception survient.

Pipes

  • Transformation et validation d'une donnĂ©e d'entrĂ©e
  • ValidationPipe, ParseIntPipe... (built-in)
  • CrĂ©ation de ses propes pipes
  • ValidationPipe permet de valider en fonction d'un modèle dĂ©fini en amont avec des dĂ©corateurs sur les propriĂ©tĂ©s du DTO (@IsString() @IsNotEmpty() @MinLength(10) etc...)
  • Par dĂ©faut, si le corps de la requĂŞte (d'oĂą le dĂ©corateur @Body()) ne correspond pas au modèle attendu, ValidationPipe interrompt le cycle RequĂŞte-RĂ©ponse pour lancer une BadRequestException (aka Error 400).

Testing

Extrait de l'article de vinceops :

Le test des composants est très largement facilité par :

  • L'injection de dĂ©pendance : toute dĂ©pendance peut ĂŞtre facilement simulĂ©e (mock) avant d'ĂŞtre passĂ©e en paramètre d'un constructeur.
  • L'aspect framework agnostic de Nest : il n'y a pas (ou rarement) besoin de mock des objets propres Ă  Express (req, res...) et toute dĂ©pendance externe (package npm, etc) peut aussi ĂŞtre injectĂ©e Ă  l'aide d'un custom provider.

Le test de l'application (End-to-End) est quelque peu facilité par la modularité de celle-ci. En effet, Nest fournit un TestingModule dans lequel on importe un à plusieurs modules pour lancer notre application. Grâce (encore) aux custom providers, on peut, au besoin, remplacer certains composants : par exemple, pour tester différentes implémentations d'une interface ILambdaService (AWS Lambda, Google Cloud Functions, ...) ou deux états d'une même implémentation (service disponible et service hors-ligne/en maintenance).

Pour les curieu(x|ses)...

  • Interceptors
  • Guards
  • GraphQL
  • OpenAPI (Swagger)
  • Microservices
  • Websockets
  • Authentication
  • Execution context (CLI, scripting...)

Conclusion

En résumé, Nest est un cadre structurant encourageant les bonnes pratiques, framework agnostique, portant une architecture modulaire, offrant de l'injection de dépendances et de puissants composants, accompagné d'intégrations élégantes, le tout écrit avec/pour TypeScript.

Liens utiles (merci Ă  eux)

You can’t perform that action at this time.