Ten en cuenta que en las ciencias informáticas un error suele tener diferentes soluciones, no obstante nosotros aquí te compartimos lo más óptimo y mejor.
Solución:
Como ya insinuó con su pregunta, los tres son conceptos muy similares y, en muchos casos, es difícil decidir y se reduce a sus preferencias. Pero puedo dar una visión general de las diferencias:
Interceptores
Los interceptores tienen acceso a la respuesta/solicitud antes y después de llamar al controlador de ruta.
Registro
- Directamente en la clase de controlador con
@UseInterceptors()controlado por el controlador o por el método - Globalmente con
app.useGlobalInterceptors()enmain.ts
Ejemplos
- LoggingInterceptor: Solicitud antes del controlador de ruta y luego su resultado. Mide el tiempo que tarda.
- Asignación de resultados: Transformar
nullpara[]o envolver el resultado en un objeto de respuesta:users->users: users
Conclusión
Me gusta que el registro esté más cerca de los controladores de rutas en comparación con el middleware. Pero existen algunas limitaciones, por ejemplo, no puede establecer el código de respuesta o modificar la respuesta con Interceptors cuando envía el response con la biblioteca específica @Res() objeto en su controlador de ruta, consulte docs.
software intermedio
El middleware se llama solo antes de que se llame al controlador de ruta. Tiene acceso al objeto de respuesta, pero no tiene el resultado del controlador de ruta. Son básicamente funciones de middleware expresas.
Registro
- En el módulo, forma muy flexible de elegir rutas relevantes (con comodines, por método,…)
- Globalmente con
app.use()enmain.ts
Ejemplos
- FrontendMiddleware: redirigir todas las rutas excepto API a
index.htmlver este hilo - Puede usar cualquier middleware express que esté disponible. Hay un montón de bibliotecas, por ejemplo
body-parseromorgan
Conclusión
El registro de middleware es muy flexible, por ejemplo: se aplica a todas las rutas menos a una, etc. Pero dado que están registrados en el módulo, es posible que no se dé cuenta de que se aplica a su controlador cuando observa sus métodos. También es genial que pueda hacer uso de todas las bibliotecas de middleware express que existen.
Filtros de excepción
Los filtros de excepción se llaman después del controlador de ruta y después de los interceptores. Son el último lugar para hacer cambios antes de que salga una respuesta.
Registro
- Directamente en la clase de controlador con
@UseFilters()controlado por el controlador o por el método - Globalmente
app.useGlobalFilters()en tusmain.ts
Ejemplos
- UnauthorizedFilter: mapa a un mensaje fácil de entender para el usuario
- NotFoundFilter: asigne todas las rutas que no se encuentran (que no forman parte de su api) a su
index.html.
Conclusión
El caso de uso básico para los filtros de excepción es dar mensajes de error comprensibles (ocultar detalles técnicos). Pero también hay otras formas creativas de uso: cuando sirve una aplicación de una sola página, normalmente todas las rutas deben redirigir a index.html excepto las rutas de tu API. Aquí, puede redirigir en un NotFoundException. Algunos pueden encontrar esto inteligente, otros hacky. Tu elección. 😉
Entonces el orden de ejecución es:
Middleware -> Interceptores -> Controlador de ruta -> Interceptores -> Filtro de excepción (si se lanza una excepción)
Con los tres, puede inyectar otras dependencias (como servicios,…) en su constructor.
Para aquellos de nosotros que “lo entendemos” mejor visualmente, he creado este diagrama de canalización de NestJs basado en el último v6.10 versión. Por favor, siéntase libre de señalar cualquier inexactitud. Lo revisaré y actualizaré de inmediato, si es necesario.
Supongo que te refieres a las tuberías en lugar de los filtros, ya que los filtros están vinculados principalmente al manejo de excepciones.
Definitivamente hay cierta superposición, ya que el Middleware es una forma flexible de componer cualquier aplicación web, pero es más un concepto genérico (crear una pila de funciones para construir una canalización). Los otros son conceptos específicos de Nest y, como tales, se vinculan un poco más naturalmente con cosas como Inyección de dependencia.
Las canalizaciones se utilizan para transformar los datos de entrada (y, opcionalmente, para realizar la validación).
Los interceptores son realmente geniales porque pueden transformar tanto los datos que entran como los que salen de su API. Le brindan la capacidad de mutar lo que el controlador original habría devuelto mediante el uso de flujos observables. Esto es algo que probablemente necesite implementar usando dos middlewares (a cada lado del controlador).
Use Pipes cuando desee transformar los datos que ingresan a un controlador.
Utilice interceptores cuando se requiera una transformación bidireccional.
Use middlewares cuando desee mantenerse más cerca de la forma tradicional (por ejemplo, Express) de crear su aplicación web o cuando desee aplicar funcionalidad de manera más amplia a muchos controladores a la vez (hay menos decoradores flotando en su código).
Tienes la opción de añadir valor a nuestro contenido informacional asistiendo con tu veteranía en las notas.