Aprende a crear APIs con Node.js utilizando JWT, testing y más

* No dudes en contactarme - dan.appdelante@gmail.com

Introducción al Curso

* Link al archivo package.json con las versiones de las dependencias que deben ser usadas: https://bitbucket.org/danmaca/diseno-apis-nodejs/src/master/package.json 
 * No dudes en contactarme - dan.appdelante@gmail.com

IMPORTANTE: Cómo Instalar Dependencias en el Curso

Creamos nuestro proyecto usando npm. Instalamos las dependencias básicas. Corremos el servidor con nuestra primera ruta.

Inicializar el Proyecto

* Creamos nuestra base de datos para los productos. Decidimos cual es la estructura de un “Producto”. Escribimos la ruta para obtener a la colección de productos, y la ruta para obtener productos mediante su ID. 
 * Aquí esta el link al video que mencione, en el te enseño como funcionan los parametros de ruta en la web: https://www.youtube.com/watch?v=prGgMrueaAA&list=PLImOJ2OqvvkDt1gVeIqsAy6oH7D0_CrGo&index=2&ab_channel=Appdelante

Rutas Básicas Para Obtener Productos

* Escribimos la ruta para crear productos. Validamos el input a la ruta de crear producto de una forma muy sencilla. Definimos el status code 400 (Bad Request). Solucionamos el problema de generar IDs usando el módulo UUID. 
 * Recuerda hacer return luego de una llamada de res.send() - esta es una fuente muy común de errores. 
 * Este es el video que mencioné acerca de APIs y los verbos de HTTP: https://www.youtube.com/watch?v=OHBHeAPoZ8E&list=PLImOJ2OqvvkDt1gVeIqsAy6oH7D0_CrGo&index=5&ab_channel=Appdelante

Ruta Para Crear Productos

* Introducimos el uso básico de la herramienta Postman 
 * Corregimos error al tratar de crear un producto. Sin body-parser el body de los request no es procesado! 
 * Aquí puedes instalar a Postman: https://www.getpostman.com/

Testing de la Ruta para Crear Productos Usando Postman

* Usamos la llamada findIndex() del módulo underscore para determinar si un producto existe en la base de datos 
 * Recuerda que PUT se utiliza para reemplazos totales, no para modificaciones parciales 
 * Este video es un poco largo. Discúlpame si te aburre! A medida que el curso avanza y vas dominando lo básico nos moveremos mucho más rápido.

Ruta para Modificar Productos que Ya Existen

* Borramos productos usando el metodo splice() de los arrays.

Ruta para Borrar Recursos de la Colección Productos

* Creamos un archivo para la base de datos.

Crear un Módulo para la Base de Datos

* Estructuramos a nuestro proyecto mediante los “recursos” sobre los que operamos. 
 * Cada recurso va a tener su propia carpeta donde vamos a localizar todo el código relacionado a ese recurso (rutas, errores, validación, etc) 
 * Las rutas se la agregamos a un “Router” de express que nuestro app utiliza. Requests destinados a /productos son enviados a este router

Crear Módulo para las Rutas de los Productos

* Este video es puramente algo de preferencia. Los cambios que hago nos permiten entender nuestro código mejor porque cada ruta queda isolada en un bloque de código apartado. 
 * Eliminamos las cadenas que inicialmente creamos con el verbo route() 
 * Empezamos a usar los verbos directamente en el router.

Eliminamos la Cadena de Verbos en el Router

* Nuestra validación es muy simple - deja muchas puertas abiertas para que el usuario haga lo que quiera con nuestra base de datos 
 * También presenta el problema de que estamos duplicando la lógica en varias rutas. La duplicación siempre apunta a un mal diseño 
 * En este video creamos un sistema de validación robusto mediante la librería Joi 
 * Definimos el diseño completo de lo que es un producto valido 
 * Encapsulamos nuestro código de validación en un middleware de express - un concepto central de este framework 
 * Recuerda que llamar a next() no significa return! Tu código volverá al middleware. Debes asegurarte de que tus returns estén estructurados correctamente 
 * Configuramos a nuestra llamada de validate() para que nos retorne todos los errores de validación 
 * Acumulamos los errores de validación usando reduce. Se los enviamos al usuario. Así es como deben ser los mensajes en un sistema de producción! Deben dar respuestas concretas al usuario sobre lo que falló 
 * Nuestro video acerca del método Reduce: https://www.youtube.com/embed/9xqJsJ3O8bw

Usamos a Joi para Validar el Body de Requests a /productos

* Este video lo creé en Junio 2020. El módulo Joi ha sido deprecado y ahora existe bajo el nombre '@hapi/joi'. 
 * En este video te muestro como migrar la validación que escribimos en el video pasado para la nueva versión de Joi.

Migramos la validación de productos a la nueva versión de Joi

* Encapsulamos la definición del blueprint y el middleware de validación en un archivo

Crear Módulo para el Código de Validación

Introducción

* Este video fue actualizado en Enero 2020 para utilizar Winston 3.x.x. Recuerda instalar la versión incluida en el package.json del repositorio en Bitbucket. 
 * Queremos saber acerca de cada evento que ocurre en nuestro servicio 
 * Estudiamos las diferentes llamadas de un Winston (info, error, debug, warn), y como la propiedad ‘level’ los controla 
 * Creamos nuestro propio logger customizado 
 * Nuestro logger utiliza un ‘transport' para que los logs persistan en un archivo, y para que sean enviados a la consola 
 * Configuramos los transports para que los logs sean muy fáciles de leer y entender

El valor de un Logger en un Sistema de Producción

* Movemos el logger a un su propio módulo 
 * Este video fue actualizado en Enero 2020

Crear un Módulo para Contener el Logger

* Configuramos el módulo Morgan para que emita logs usando nuestro logger customizado

Integrar Morgan con Winston para Loggear Data de Requests

* Ponemos a la práctica nuestro logger que llevamos construyendo en los pasados videos 
 * Estudiamos la auditoría generada por llamadas de prueba usando Postman

Usamos el Logger en las Rutas y Código de Validación

Configuración y uso de un Logger

* Explicamos la motivación de los próximos videos: explorar diferentes formas de proteger nuestras rutas 
 * Recuerda, autenticación se refiere a como compruebas tu identidad, y autorización a que derechos tienes en un servicio

Dos Fundamentos de Seguridad: Autenticación y Autorización

* Definimos que significa “proteger” una ruta con autenticación 
 * En pocas palabras, un middleware se encarga de verificar si las credenciales son correctas 
 * Configuramos a Passport para que utilice la estrategia básica de autenticación 
 * Recuerda que debemos definir una función la cual se encargue de validar si credenciales (usuario / contraseña) son válidas 
 <blockquote>* Esta función usualmente llamaría a una base de datos, pero como todavía no tenemos una para los usuarios hacemos ‘hardcoding’ de credenciales directamente en la función</blockquote>
 <blockquote>* Solo el usuario ‘daniel’ con contraseña ‘appdelante123’ se podrá autenticar</blockquote>
 * Accesamos una ruta protegida mediante un navegador 
 * Este método de autenticación no es muy bueno para un servicio. Incluir username y password en cada request es inseguro y le da más trabajo al consumidor de nuestro servicio. 
 * En lugar de este método vamos a utilizar uno llamado JSON Web Tokens (JWT). Con JWT solo tendremos que procesar la contraseña de cada usuario una vez. Al verificar que las credenciales son correctas, enviaremos al usuario un token que les da acceso temporal a las rutas protegidas. Este sistema es muy similar al que compañías como Twitter utilizan.

Proteger Rutas con Autenticación Básica (Usuario y Password)

* Creamos una nueva “base de datos” para los usuarios (por los momentos, un array en la memoria)

Crear Base de Datos en la Memoria para Guardar Usuarios

* Utilizamos Joi para validar que el request para crear un usuario tienes las propiedades necesarias (email, contraseña, username)

Validar Requests para el Registro de Usuarios

* Nuestra ruta de registro responde con el status ‘409’ (Conflict) en caso de que el username o email ya esten en uso. 
 * ¡Ten mucho cuidado con los logs en la ruta de registro! No queremos que emails o contraseñas aparezcan en los logs de nuestro servicio. Esta información es ultra-sensible y debemos manejarla con mucho cuidado. 
 * Hasheamos las contraseñas usando el módulo bcrypt. Esta operación consiste en pasar a la contraseña por una función matemática que genera una huella digital. Esta huella es lo que guardamos en la base de datos. Nunca debes guardar contraseñas tal como llegan en un request en la base de datos, es muy inseguro. 
 * El hashing de contraseñas es irreversible. Esto significa que teniendo un hash la única forma de volver a la contraseña que le corresponde es probando todas las contraseñas posibles, lo cual podría tomar cientos de años! 
 * Debemos tener cuidado con lo que revelamos en el response de nuestra ruta de registro. No queremos revelar información al client que no necesita.

Crear Dos Rutas: Registro de Usuarios y Obtener Usuarios

* Corregimos un pequeño error en el import de validación 
 * Limpiamos los logs de validación de contraseña, email y username 
 * ¡Disculpas por estos errores! Es difícil evitar bugs y grabar al mismo tiempo

Testing del Registro de Usuarios con Postman

* Extraemos el callback de autenticación y lo ponemos en un módulo llamado ‘auth.js' 
 * Volvemos a implementar el código de ese callback para que busque usuarios en la base de datos 
 * Hacemos testing de la ruta con Postman

Remover credenciales 'hardcoded'. Verificar login usando DB.

* Rápidamente explico como Twitter utiliza tokens para proteger su API. En los siguientes videos del curso vamos a montar nuestro propio sistema de autenticación mediante JSON Web Tokens (JWT), uno de los sistemas más modernos de autenticación 
 * En el siguiente video vamos a escribir una ruta de ‘login’, la cual le entregará a los usuarios un Token de autenticación

Exploramos como Twitter usa Tokens para Autenticar sus APIs

* El código de la librería auth.js es la base para nuestra ruta de login. Solo tenemos que modificar algunas partes para enviar responses en lugar de llamar al callback ‘done' 
 * Instalamos el módulo jsonwebtoken (jwt) 
 * Para generar tokens con jwt utilizamos un secreto. En un token podemos guardar información que luego podemos accesar al decriptarlo. Por ahora vamos a guardar el id del usuario que envió el request de login 
 * Este último paso involucra que modifiquemos un poco el registro de usuarios para otorgarle a cada usuario un id, similar a como lo hacemos con productos. Este paso es esencial, porque más adelante cuando migremos a MongoDB todos los documentos van a tener un id único 
 * Nuestro secreto por los momentos es un string hardcoded. ¡Más adelante vamos a corregir este detalle!

Crear Ruta de Login para Generar Tokens de Autenticación

* Escribimos el middleware para validar que los pedidos de login tengan un username y contraseña

Validación de Pedidos de Login con Joi

* Este video lo creé en Junio 2020. El módulo Joi ha sido deprecado y ahora existe bajo el nombre '@hapi/joi'. 
 * En este video te muestro como migrar el código de validación que escribimos en este módulo del curso a la nueva versión de Joi. 
 * Como mencioné en el video, aquí esta el video del módulo de introducción donde hacemos esta misma migración pero para la validación de productos: https://appdelante.com/cursos/diseno-de-apis-con-node-js/migramos-validacion-productos-nueva-version-joi

Migramos la validación de requests a usuarios y login a la nueva versión de Joi

* Migramos de la estrategia básica de autenticación a una que verifique los tokens de JWT 
 * La estrategia de JWT recibe el token del usuario, y lo decripta. Ese token decriptado lo llamamos el ‘payload’, y contiene al ID del usuario 
 * El módulo passport-jwt nos permite agregar información al objeto de request antes de pasarlo a la siguiente función en la cadena de middlewares. En nuestro caso agregamos el ‘username’ y ‘id’ del usuario al request 
 * Tenemos el secreto de JWT copiado en dos archivos, lo cual es terrible. Dentro de poco vamos a corregir este detalle cuando creemos el módulo de configuración del proyecto 
 * Mediante la propiedad de configuración ‘jwtFromRequest’ especificamos que el token nos va a llegar como un header en el request. En el siguiente video verás como se utiliza este header en Postman.

Crear Estrategia de Autenticación con el Módulo passport-jwt

* Integramos la estrategia de jwt y mostramos como el header ‘Authorization’ debe ser usado para especificar el token 
 * El valor del header ‘Authorization’ empieza con la palabra ‘Bearer’, seguido por el token. Así lo especifica el protocolo.

Integrar la Estrategia de JWT con la Aplicación

* No pasamos el objeto completo de un usuario porque estaríamos haciendo que la contraseña pudiese ser accesada desde cualquier ruta protegida 
 * ¡Esto es un gran riesgo a la seguridad de nuestra aplicación!

¿Por Qué no Agregar al Usuario Completo a req.user?

* Empezamos por proteger la ruta para crear productos 
 * En express podemos tener varios middlewares en una ruta, simplemente hay que ponerlos en una lista antes del callback de la ruta 
 * Ahora los productos tienen una propiedad llamada ‘dueño’. ¡Esta es la razón por la cuál agregamos la información del usuario al validar un token! 
 * Protegemos también a la ruta de PUT para modificar productos. Modificamos el código para que solo el dueño de un producto lo pueda modificar 
 * Por último, modificamos la ruta DELETE para que solo el dueño de un producto pueda borrar los productos que le pertenecen

Protegemos las Rutas de Productos con la Estrategia de JWT

* En este video corremos tests manuales de las rutas protegidas con tokens usando Postman. ¡Los tests son un poco complicados! Sin embargo, nuestro sistema de JWT esta funcionando perfectamente. Más adelante en el curso vamos a escribir tests automáticos para no tener que seguir haciendo pruebas manuales.

Testing de Rutas Protegidas usando Postman

Proteger las Rutas: Autenticación y Autorización

* Tenemos la configuración de nuestro API regada en muchos archivos. Si logramos centralizar toda la configuración en un solo lugar tendremos código mucho más limpio y fácil de mantener 
 * Creamos un módulo llamado ‘config’ que contiene la configuración de nuestro proyecto 
 * Nuestro servidor corre en diferentes ‘ambientes’ o ‘etapas': 
 <blockquote>* ‘dev’ o ‘desarrollo’ se utiliza cuando estamos construyendo nuevos features. En todo este curso siempre estamos corriendo en ‘dev’ porque estamos construyendo el servicio</blockquote>
 <blockquote>* ‘prod’ o ‘producción’ se utiliza cuando el sistema está sirviendo tráfico real de nuestros usuarios</blockquote>
 * Usar diferentes ambientes nos permite no tener que usar los secretos de producción en desarrollo. Es muy importante que esos secretos solo existan en máquinas que están corriendo nuestro API 
 * Tener diferentes etapas nos da mucha versatilidad a la hora de correr el servicio. Por ejemplo, quizás en desarrollo queremos que los tokens nunca expiren, pero en producción definitivamente no queremos esto. 
 * Especificamos en que etapa corre nuestro servicio mediante variables de ambiente

Centralizar la Configuración del Servicio

Configuración de un API

* En los próximos videos vamos a migrar de nuestra base datos en la memoria a MongoDB 
 * La base de datos en la memoria es volátil. Cuando el proceso de Node muere, nuestra base de datos desaparece 
 * Vamos a utilizar a MongoDB, una base de datos NoSQL 
 * ¿Por qué MongoDB? Opción popular muy usada en la industria. Nos va a permitir explorar en detalle promesas y asincronía. ¡Pronto verás código mucho más interesante y realmente de producción! s
 * Vamos a tener que pensar de nuevas maneras de manejar errores

Necesitamos una Base de Datos

* Página para instalar a MongoDB: https://www.mongodb.com/download-center?jmp=nav#community 
 * Instrucciones para correr a mongod en Windows 10: https://www.youtube.com/embed/2KMQdqDk9e8

Como Instalar y Correr a MongoDB

* En NoSQL no existen tablas ni columnas (como es en el caso de SQL). En su lugar, tenemos a colecciones y documentos 
 * NoSQL es un paradigma muy flexible. No tenemos que especificar desde el principio que contiene exactamente un documento. Podemos simplemente agregar y quitar propiedades cuando queramos 
 * En SQL uno debe escribir que columnas existen en cada tabla. Es un modelo inflexible. Uno debe saber perfectamente que debe contener cada fila 
 * Recuerda que 127.0.0.1 se refiere a localhost. Debes a MongoDB corriendo para que la conexión sea exitosa

Conectar nuestro servidor a MongoDB. Fundamentos de NoSQL

* Los ‘schemas’ nos permiten definir que propiedades debe tener un documento que va a nuestra base de datos 
 * No pienses en ellos como filas en una tabla, son más bien documentos flexibles que pueden variar mucho entre ellos 
 * Verás que este código se parece mucho a la validación que hicimos con Joi. Si son similares, pero sirven dos propósitos distintos. Joi válida los requests que llegan al servidor, mientras que los ‘schemas’ definen que podemos guardar en la base de datos.

Definir el ‘schema’ de un Producto

* Mediante el Schema de producto guardamos nuevos productos en MongoDB 
 * Fíjate que la llamada a .save() nos retorna una promesa. Es por eso que llamamos a los métodos .then() y .catch() 
 * Recuerda que las promesas son llamadas asíncronas que eventualmente se completan. Al completarse exitosamente se llama a .then(), y si ocurre un error se llama a .catch()

Migramos Ruta de Crear Productos para que Utilize a MongoDB

* Hacer llamadas directas a Mongoose desde nuestras rutas establece una integración muy fuerte entre dos cosas totalmente distintas 
 * ¡Separarlas hace que nuestro código sea mucho más fácil de mantener en el futuro! Es por ello que creamos un módulo llamado el controlador de productos 
 * He hablado mucho sobre este tema. Asegurarse de que tus dependencias no estén integradas fuertemente con tus módulos tendrá un gran impact en tu código

Creamos un módulo Para las Operaciones de Base de Datos

* Quizás te estás preguntando, ¿Cómo puede fallar una promesa de MongoDB? 
 * ¡De muchísimas maneras! Si tu disco no tiene espacio, verás a la promesa de crear producto fallar. Si la base de datos estuviese en la red, es muy posible que una lectura podría fallar por una mala conexión. Estos son solos algunos ejemplos. Recuerda, nunca dejes que tu aplicación se trague un error; asegurarte de loggearlo o de alguna forma notificarte que algo falló

Migrar Ruta para Obtener Productos. Testing con Postman

* Al final de este video vemos como IDs que no pueden ser transformados a Object IDs hacen que MongoDB tire un error. Podemos prevenir este comportamiento mediante un middleware que verifique que los ID’s son válidos antes de hacer la llamada a MongoDB. Esto lo verás en el próximo video

Migrar Ruta para Obtener Productos Individuales

* Mediante unas pocas líneas de código nos aseguramos de que el callback de la ruta GET /producto/:id solo sea llamado con IDs válidos 
 * Los “Regular Expressions” son una herramienta extremadamente poderosa que está presente en prácticamente todos los lenguajes de programación. Son cómo un lenguaje estandarizado para hacer búsquedas en texto. Yo podría hacer un curso completo acerca de solo este tema, por ello solo lo veremos superficialmente. Sin embargo, te recomiendo que leas acerca de ellos, ¡Son muy útiles!

Crear Middleware para Validar IDs

* Nuestro video acerca de Async / Await: https://www.youtube.com/embed/u2axmPnxUoo 
 * Usando Async / Await vemos como el flow de control en esta ruta se lee muy fácilmente. Si hubiésemos usado a .then() y .catch() tendríamos varios niveles de indentación que harían bastante complicado saber lo que esta pasando 
 * Más adelante en el curso vamos a visitar de nuevo la forma en que atrapamos los errores con el try / catch. ¡Vamos a eliminar los try / catches completamente! Nuestro código empieza a verse más y más como algo que puede correr en un sistema de producción

Migrar Ruta de Borrar Productos y Asincronía con Async/Await

Testing de la Ruta para Borrar Productos Usando Postman

* Recuerda que para usar async / await debes poner ‘async’ antes del callback. Esta es la sintaxis definida por ES6 
 * La propiedad ‘new’ en el objeto de configuración a findOneAndUpdate() hace que la llamada retorne el producto que resulta de la modificación

Migrar la Última Ruta de Productos - PUT /productos/:id

* ¡Seguimos haciendo testing con Postman! Probablemente estarás pensando “Maldición! Que fastidio ver testing manual otra vez!” - ¡Te escucho! Ten algo de paciencia que al final del curso vamos a escribir tests completamente automáticos. Salta estos videos si te aburren, pero no dejes de ver el curso que lo que viene es súper interesante

Testing de la Ruta para Modificar Productos Usando Postman

* Loggear un objeto de Mongoose incluye muchas propiedades y funciones que no queremos ver. Esto contamina nuestros logs y los hace difícil de leer 
 * Utilizamos la función toObject() para solo loggear el JSON de los productos 
 * Este video salió en Enero 2020

Corrección en Como Loggeamos Objetos de Mongoose

* Creamos el schema y también el módulo ‘controlador’ que contiene las llamadas a MongoDB 
 * Recuerda que la ruta para obtener la colección de usuarios es solo para desarrollo. Nunca deberíamos exponer a toda la información de nuestros usuarios, a no ser que eso es algo que realmente necesitas en tu servicio

Definir el ‘schema’ de un Usuario. Migrar ruta GET /usuarios

* En este video nos enfocamos en escribir la llamada del controlador para verificar que los datos de un nuevo usuario no están asociados con otro usuario 
 * Fíjate en como la llamada usuarioExiste() del controlador debe retornar una promesa. Esto lo hacemos creando la promesa manualmente y llamando a resolve() una vez que la operación asíncrona de MongoDB se haya completado 
 * ¡Retornar ‘true’ o ‘false’ desde el .then() a la llamada de MongoDB no funcionaría! Recuerda que ese return es para el callback que .then() esta ejecutando, no para la llamada a usuarioExiste() del controlador. Este detalle es difícil de entender para quiénes son nuevos a JavaScript. Estudia y juega mucho con este código

Migrar Ruta Para Crear Usuarios - Parte 1

* Ahora que definimos la llamada usuarioExiste() podemos terminar de escribir la lógica de crear usuario 
 * Recuerda que luego de usar el operador spread (…) podemos sobre-escribir propiedades si las redefinimos. Esto lo hacemos en esta ruta con el atributo ‘password’

Migrar Ruta Para Crear Usuarios - Parte 2

Testing de la Ruta para Crear Usuarios Luego de la Migración

* Nuestro servicio tiene un gran problema: respeta la capitalización de usuarios e emails 
 * Esto significa que dos usuarios pueden tener usernames idénticos que solo varían en su capitalización 
 * Piensa en las consecuencias de esta decisión. Es fácil impresionar a otros a usuarios y es fastidioso para los usuarios hablar de sus cuentas. “Mi username es daNIEL. La N, I, E, y L son mayúscula” - ¿Te imaginas una conversación como esta? 
 * Para corregir este problema forzamos los usernames y emails a que sean lowercase luego de validar el request

Forzar los Usernames y Emails a que Sean Minúsculas

* Para empezar creamos la función obtenerUsuario() en nuestro controlador la cual utiliza ‘Object Destructuring’ (destructuración de objetos) para que nos permita obtener usuarios mediante un ID o username. Este feature es super poderoso y nos permite crear funciones muy flexibles

Migrar Ruta de Login - Parte 1

* Fíjate en como utilizamos a async / await con la llamada bcrypt.compare() - podemos usar async / await con cualquier operación asíncrona 
 * Lo que queda por migrar del sistema de login es nuestro archivo auth.js que se encarga de validar tokens

Migrar Ruta de Login - Parte 2

* Rápidamente modificamos el código en auth.js para que busqué usuarios en MongoDB y no en la base de datos en la memoria

Migrar Código de Validación de Tokens

* Borramos a database.js 
 * Verificamos que ningún otro archivo todavía depende de este módulo usando la herramienta ‘grep’ en la terminal

Eliminar a la Base de Datos en la Memoria Completamente

Migración a MongoDB

* Quizás habrás notado como repetimos el mismo patrón de responder con un estatus de 500 cuando una llamada asíncrona falla. ¡Esto esta en prácticamente cada ruta que escribimos! 
 * Nuestro objetivo es centralizar esta lógica que responde con el estatus 500. Queremos que el manejo de los errores en los catches ocurra en un solo lugar sin que tengamos que repetir la misma lógica 
 * Este es quizás el video mas complicado de todo este curso. Cubrimos conceptos de JavaScript realmente avanzados. Dedica mucho tiempo a este segmento y escribe el código con el que jugamos para que domines los conceptos

¿Cómo Podemos Mejorar el Manejo de Errores?

* En este video integramos a la función procesarErrores con la ruta para crear productos 
 * Esto es posible porque el catch() que asignamos mediante procesarErrores es quien recibe el error que emitimos desde el controlador de productos 
 * ¡Sigue mirando! Todo debe empezar a hacer mas sentido

La Función procesarErrores()

* Siempre debemos manejar los errores. Nunca debemos tragarlos silenciosamente. 
 * Ahora que podemos agarrar los errores mediante la función procesarErrores() vamos a crear “Error Handling Middlewares” (Middlewares para el manejo de errores). Estas son funciones que se encargan específicamente de procesar errores 
 * Al llamar a next(err) Express busca el primer middleware capaz de manejar errores y le entrega el request y el response. ¿Cómo sabe Express que middleware puede manejar errores? ¡Mediante ese parámetro ‘error’! 
 * Si una ruta tiene como primer parámetro a ‘error’ entonces es un middleware para manejar errores 
 * En este video creamos nuestro primer middleware para manejar errores: ‘procesarErroresDeDB(err, req, res, next)' 
 * Este middleware llama a otro middleware porque al final invoca a next(err) 
 * Este siguiente middleware va a ser erroresEnDesarrollo(err, req, res, next) o erroresEnProducción(err, req, res, next). Estas dos funciones están al final de nuestra cadena de middlewares para manejar errores 
 * No te quedes estancado en este video. Sigue mirando que pronto todo hará sentido

Middlewares de express Para Manejo de Errores

* Mediante app.use() le decimos a express que nuestros middlewares para manejo de errores deben ser usados 
 * Envolvemos a nuestras rutas de productos con la función procesarErrores() 
 * Las funciones que usan a async / await siempre retornan una promesa implícitamente. Es decir, incluso cuando no tienen un return que tu veas pues siempre retornarán una promesa. Así es como funciona async / await internamente en JavaScript. Esto nos hace la vida más fácil, ya que la función procesarErrores() necesita que la ruta regrese una promesa. 
 * Al envolver a una función async / await en procesarErrores podemos borrar los try / catches y los catch() de las llamadas asíncronas 
 * En este video también envolvemos a las rutas de usuarios con la función procesarErrores() 
 * En la ruta para crear usuarios tenemos que hacer algunos cambios para asegurarnos que los errores siempre sean procesados. Debemos eliminar las promesas profundas y simplemente usar una cadena de then(). Recuerda que un then() siempre retorna una promesa también. 
 * En esta ruta también debemos usar un error customizado. Como expliqué en el video, nuestro return y res.send() no están teniendo ningún efecto. Debemos lanzar un error para que el detener la ejecución en el then() e ir al catch()

Configurar express Para Que Utilize Middlewares de Errores

* Podemos eliminar código duplicado creando errores customizados. Esta es una de las grandes ventajas de nuestro nuevo sistema para procesar errores

Errores Customizados Para las Rutas de Usuarios

Errores Customizados Para las Rutas de Productos

Manejo de Errores en Producción

* Explico porque dejamos los tests para el final del curso, y porque esto no es un buen patrón de desarrollo 
 * Explico las diferencias entre Unit Tests y Integration Tests

¿Cómo Haremos Testing de Nuestro API?

* Instalamos lost módulos Jest y Supertest 
 * Utilizamos la función describe() para estructurar nuestros tests 
 * Utilizamos la función beforeEach() para borrar la colección Usuarios antes de cada test 
 * Utilizamos la función afterAll() para matar el servidor al final de los tests 
 * Utilizamos la función expect() para verificar que la respuesta de nuestro servidor tiene los parámetros que esperamos

Configuración del Test Runner y Primer Test a GET /usuarios

* Verificamos que si existen usuarios la llamada a GET /usuarios los retorna

Terminar Tests a GET /usuarios

* Crear un usuario depende de muchas condiciones. En este video escribimos tests para cubrirlas todas

Escribir Tests para Crear Usuarios - POST /usuarios

* Cubrimos todos los posibles caminos que nuestro código puede seguir a la hora de validar credenciales 
 * Verificamos que el token es válido generándolo directamente en el test

Escribir Tests para Login - POST /usuarios/login

* ¡Gracias a nuestros tests descubrimos un bug en la validación de los requests para crear productos! 
 * Fíjate que genial cómo usando la librería supertest podemos hacer un ‘workflow’ de login. Es decir, creamos un usuario y luego enviamos sus credenciales para obtener un token. ¡En pocas líneas de código hicimos muchísimo!

Escribir Tests Para Obtener y Crear Productos

Escribir Tests Para Borrar Productos

* ¡Se que no quieres escribir tests! Pero si decides hacerlo vas a sacarle muchísimo provecho a este curso 
 * Los tests son una parte fundamental de un sistema de producción. Gran parte de tu tiempo debe estar invertido en escribir tests para tu sistema

¡Te Toca a Ti Escribir Tests! La Ruta PUT /productos/:id

* Fíjate lo poderoso que es nuestro sistema de configuración. Rápidamente podemos crear un nuevo atributo para suprimir logs de la consola al correr los tests 
 * El flag ‘—coverage’ de Jest es extremadamente útil. ¡Tenemos muy buenos números de coverage en nuestro proyecto! Eso significa que hicimos ‘testing’ de nuestro código muy efectivamente

Suprimir Logs al Correr Tests y Análisis de ‘coverage’

* Cerramos la conexión a MongoDB luego de correr los tests. Esto nos permite dejar de usar --forceExit 
 * Hacemos unos cuantos cambios de configuración al módulo Mongoose, el cual ha cambiado un poco desde que filmé los videos del curso

No Usar --forceExit y Cambios Para Eliminar Advertencias de Mongoose

* Déjame saber que te pareció el curso. Escríbeme a dan.appdelante@gmail.com 
 * Si quieres complementar lo que aprendista acá con un curso de Front End, te recomiendo nuestro curso de React

Fin del Curso

Testing de APIs

Decidí extender el curso de Diseño de APIs con un nuevo módulo en el cual explico como subir imágenes en un sistema de producción.

Introducción a la extensión del curso

Creamos la ruta básica para recibir las imágenes del cliente. Utilizamos a la función raw() del módulo body-parser para que imágenes de ciertos tipos sean procesadas y dispuestas en req.body.

Ruta básica y parsing del body del request

Mediante la configuración del módulo body-parser rechazamos las imágenes que son mayores a 1 Mb. Creamos un middleware para manejar este error y enviar a los usuarios un mensaje detallado de porque su request falló.

Rechazar imágenes muy grandes

Es muy importante verificar que los que nos envían los usuarios en su request es realmente una imagen. No hacer esto puede resultar en ataques a nuestro servicio y que ciertas partes de la aplicación dejen de funcionar.

Demostración de como Github valida las fotos de perfil

Mediante el módulo file-type filtramos los requests de forma que solo sean procesados aquellos que tienen imágenes de tipo jpeg, jpg y png. También escribimos código de validación para no procesar requests que tengan el Content-Type que queremos. Esto es una parte crucial de un sistema de producción.

Verificar que recibimos una imagen real

Mediante Postman verificamos que nuestros mecanismos de validación están funcionando.

Testing con Postman de la validación de imágenes

Evaluamos tres diferentes formas de guardar las fotos: en la memoria, en el disco o en un servicio externo como Amazon S3. Concluimos que para un servicio de producción necesitamos algo que crezca junto con los requerimientos de nuestro servicio. <a href="https://www.youtube.com/watch?v=3qGVkJQgiWY&list=PLImOJ2OqvvkBaMACVK_jhTLqRiKEDDECj">Link a serie acerca de S3</a>

Decidimos donde almacenar las imágenes

Instalamos el módulo aws-sdk y lo utilizamos para crear un cliente que pueda interactuar con S3. Para entender bien como funciona IAM te recomiendo que veas la siguiente serie de videos que publiqué cuando me uní a Appdelante.

Crear y configurar cliente de AWS S3

Creamos una simple función para subir imágenes a S3 mediante una llamada a la función putObject() del cliente. A esta función le pasamos un Buffer que contiene la data de la imagen, el nombre del “Bucket” en S3 donde queremos guardar la imagen, y la dirección especifica en la que queremos guardar la imagen en el Bucket.

Crear función para subir imágenes a S3

Modificamos la ruta /:id/imagen para que llame a la función guardarImagen() definida en el controlador de imágenes. Fíjate que generamos un nombre randomized para cada imagen. Hacemos esto porque queremos evitar conflictos entre los nombres de los archivos que los usuarios nos envían. También es importante resaltar que todos los archivos en el Bucket son públicos. No hay ningún tipo de autenticación a la hora de obtenerlos. Usar nombres random previene que alguien con un diccionario pueda fácilmente bajar información de nuestro bucket.

Modificar ruta para subir imágenes a S3

Lo único que falta es modificar al documento del producto de forma que contenga el URL de la imagen que fue subida por el usuario. Al hacer esto, llamadas al API para obtener productos retornará la locación donde puede ser descargada la imagen. Un browser puede usar ese URL en un <img> tag para mostrarla.