Quelle est la différence entre Interceptor vs Middleware vs Filter dans Nest.js ?

Question

Quelle est la différence entre un Interceptor, un Filter et un Middleware dans le framework Nest.js ? Quand faut-il utiliser et privilégier l'un d'entre eux par rapport à l'autre ?

Merci

Answer 1

Comme vous l'avez déjà laissé entendre dans votre question, les trois sont des concepts très similaires et, dans de nombreux cas, il est difficile de se décider et tout dépend de vos préférences. Mais je peux vous donner un aperçu des différences :

Intercepteurs

Les intercepteurs ont accès à la réponse/requête avant y après que le gestionnaire de route soit appelé.

Inscription

• Directement dans la classe du contrôleur avec @UseInterceptors() à l'échelle du contrôleur ou de la méthode
• Globalement avec app.useGlobalInterceptors() en main.ts

Exemples

• LoggingInterceptor : Demande avant le gestionnaire de route et ensuite son résultat. Mesurer le temps que cela prend.
• Cartographie des résultats : Transformer null a [] ou envelopper le résultat dans un objet de réponse : users -> {users: users}

Conclusion

J'apprécie le fait que l'enregistrement soit plus proche des gestionnaires de route que de l'intergiciel. Mais il y a quelques limitations, par exemple, vous ne pouvez pas définir le code de réponse ou modifier la réponse avec les Intercepteurs lorsque vous envoyez la requête response avec la bibliothèque spécifique @Res() dans votre gestionnaire de route, voir docs .

Middleware

L'intergiciel n'est appelé qu'avant l'appel du gestionnaire de route. Vous avez accès à l'objet réponse, mais vous n'avez pas le résultat du gestionnaire de route. Il s'agit essentiellement de fonctions middleware express.

Inscription

• Dans le module, possibilité très souple de choisir des itinéraires pertinents (avec des jokers, par méthode,...)
• Globalement avec app.use() en main.ts

Exemples

• FrontendMiddleware : redirige toutes les routes sauf l'API vers index.html , ver ce fil
• Vous pouvez utiliser n'importe quel intergiciel express existant. Il existe lots des bibliothèques, par exemple body-parser o morgan

Conclusion

L'enregistrement des intergiciels est très flexible, par exemple : appliquer à toutes les routes sauf une, etc. Mais comme ils sont enregistrés dans le module, vous pouvez ne pas vous rendre compte qu'ils s'appliquent à votre contrôleur lorsque vous examinez ses méthodes. C'est également une bonne chose que vous puissiez utiliser toutes les bibliothèques de middleware express qui existent.

Filtres d'exception

Les filtres d'exception sont appelés après le gestionnaire de route et après les intercepteurs. Ils sont le dernier endroit où l'on peut apporter des modifications avant l'envoi d'une réponse.

Inscription

• Directement dans la classe du contrôleur avec @UseFilters() à l'échelle du contrôleur ou de la méthode
• Globalement app.useGlobalFilters() dans votre main.ts

Exemples

• UnauthorizedFilter : Correspond à un message facile à comprendre pour l'utilisateur.
• NotFoundFilter : Mapper toutes les routes qui ne sont pas trouvées (ne faisant pas partie de votre api) à votre index.html .

Conclusion

Le cas d'utilisation de base des filtres d'exception consiste à fournir des messages d'erreur compréhensibles (en masquant les détails techniques). Mais il existe également d'autres modes d'utilisation créatifs : Lorsque vous servez une application à une seule page, toutes les routes doivent rediriger vers index.html sauf les routes de votre API. Ici, vous pouvez rediriger sur une NotFoundException . Certains peuvent trouver cela intelligent, d'autres le trouveront bricolé. À vous de choisir ;-)

---

Donc l'ordre d'exécution est :

Middleware -> Intercepteurs -> Route Handler -> Intercepteurs -> Filtre d'exception (si une exception est levée)

Avec les trois, vous pouvez injecter d'autres dépendances (comme des services,...) dans leur constructeur.

Answer 2

Pour ceux d'entre nous qui comprennent mieux visuellement, j'ai créé ce digramme du pipeline NestJs basé sur le dernier v6.10 version. N'hésitez pas à me signaler toute inexactitude. Je les reverrai et les mettrai à jour rapidement, si nécessaire.

Answer 3

Je suppose que vous voulez dire Pipes au lieu de Filters, car les Filters sont principalement liés à la gestion des exceptions.

Il y a certainement un certain chevauchement, car les intergiciels sont un moyen flexible de composer n'importe quelle application Web, mais il s'agit plutôt d'un concept générique (création d'une pile de fonctions pour construire un pipeline). Les autres sont des concepts spécifiques aux niches et, en tant que tels, ils sont liés un peu plus naturellement à des choses comme l'injection de dépendances.

Les tuyaux sont utilisés pour transformer les données d'entrée (et éventuellement pour effectuer une validation).

Les intercepteurs sont vraiment intéressants car ils peuvent transformer les données qui entrent et sortent de votre API. Ils vous donnent la possibilité de modifier ce que le gestionnaire d'origine aurait renvoyé grâce à l'utilisation de flux observables. Il s'agit d'une fonction que vous devrez probablement mettre en œuvre en utilisant deux intergiciels (de part et d'autre du gestionnaire).

Utilisez les pipes lorsque vous souhaitez transformer les données qui arrivent dans un gestionnaire.

Utilisez les intercepteurs lorsqu'une transformation bidirectionnelle est nécessaire.

Utilisez des intergiciels lorsque vous souhaitez vous rapprocher de la méthode traditionnelle (par exemple, Express) de construction de votre application Web ou lorsque vous souhaitez appliquer plus largement des fonctionnalités à de nombreux gestionnaires à la fois (il y a moins de décorateurs flottant dans votre code).