Me uní a un pequeño equipo de desarrolladores para una puesta en marcha. Ni siquiera hemos lanzado todavía. Me han entregado un servicio backend escrito en node/express. No he trabajado con esta tecnología más allá de pequeños proyectos favoritos. Estaba buscando implementar una guía de estilo solo para mantener la coherencia del código, con el objetivo de implementar esto también en otros servicios de back-end.
Eso me llevó a la guía de estilo de Airbnb. Esta parte me llamó la atención. Nunca cambie los parámetros
// bad function f1(obj) { obj.key = 1; } // good function f2(obj) { const key = Object.prototype.hasOwnProperty.call(obj, 'key') ? obj.key : 1; }En Express, normalmente hay controladores que se definen así:
async function someController(req, res, next) { // I've seen similar code to this req.someNewProp = "Some new value." res.status(200).json({"someJSONKey":"someJSONVal"}); }El middleware generalmente se define así:
// Route router.get('/endpoint', function1, function2) async function function1(req, res, next) { // I've seen similar code to this req.someNewProp = "Some new value." // Pass req and res to function2 next(); } Me doy cuenta de que el objeto req , a medida que se pasa, se modifica mucho. Los datos se agregan a este objeto en el middleware y otras funciones a medida que se transmiten antes de que se devuelva la respuesta. El desarrollador original que creó el código se refirió a él como "mantener las cosas en el alcance de la solicitud". Pero eso parece contradecir directamente un punto importante en la guía de estilo y me hizo preguntarme si esto es una mala práctica.
Entonces, la pregunta ahora es, ¿existe una forma "mejor" o más ampliamente aceptada de realizar un seguimiento de las cosas en el contexto de la solicitud que no está mutando el objeto de solicitud original? ¿Cuáles son algunos enfoques para hacer esto?
Express proporciona un espacio de nombres para que las aplicaciones almacenen variables de procesamiento de solicitud/respuesta al agregarlas como propiedades de res.locals . Esta parece una mejor opción que adjuntar propiedades no estándar a los propios objetos de solicitud o respuesta.
De manera similar, las variables de aplicación global se pueden almacenar como propiedades de app.locals
Desafortunadamente, no parece haber una propiedad locals definida para las instancias del router . Coloqué una referencia a las opciones de instancia de enrutador global en res.locals como el primer paso de middleware en una ruta que escribí, pero esa fue mi elección.
Puede suceder que las propiedades de la solicitud deban cambiarse durante el procesamiento, como req.path , pero esto no es algo que se deba evitar a toda costa. Por ejemplo, Express proporciona req.originalURL para que pueda volver a calcular los componentes de la ruta en cualquier momento que lo necesite mediante un diseño deliberado .
Es posible que Express se vuelva más interesante con el uso: recientemente me enteré y pasé un argumento de objeto de error a la next función. En cuanto a la cita de la guía de Airbnb en la publicación: ¡decepcionante en una palabra! El código "bueno" y "malo" citado en la publicación no hace lo mismo .
No es una mala práctica, esta es la idea detrás del middleware en express, en la definición simple, los middlewares son funciones que pueden modificar el objeto de solicitud y respuesta o incluso decidir si el flujo de la solicitud continúa o se termina. Sin embargo, debe tener cuidado y no establecer un valor en una propiedad preexistente o puede tener algunos comportamientos extraños, además, si la información que va a almacenar en la solicitud es grande, puede pensar en otras estrategias para Instancia almacena la información en una base de datos de memoria como Redis .
Después de revisar los documentos expresos, encontré este bit en la sección de middleware:
Las funciones de middleware pueden realizar las siguientes tareas:
- Ejecutar cualquier código.
- Realice cambios en los objetos de solicitud y respuesta.
- Terminar el ciclo de solicitud-respuesta.
- Llame a la siguiente función de middleware en la pila.
Entonces, probablemente sea seguro decir que si los documentos dicen explícitamente que podemos modificar los objetos de solicitud y respuesta en el middleware, probablemente no sea una mala práctica.