Tu primera experiencia con Node.js

1

¿Dónde aprender backend con Node.js actualizado?

2

Todo lo que aprenderás sobre backend con Node.js

3

¿Qué es Node.js?

4

¿Qué es Node.js y para qué sirve?

5

Diferencias entre Node.js y JavaScript

6

Resumen: Diferencias Nodejs y Javascript

7

Instalación de Node.js

8

Arquitectura orientada a eventos

9

Node.js para la web

Manejo y uso de Streams con Node.js

10

Introducción a streams

11

Readable y Writable streams

12

Duplex y Transforms streams

Uso de utilidades de Node.js

13

Sistema operativo y sistema de archivos

14

Administrar directorios y archivos

15

Consola, utilidades y debugging

16

Clusters y procesos hijos

Crea tu primer proyecto en Express.js

17

¿Qué es Express.js y para qué sirve?

18

Creando tu primer servidor con Express.js

19

Request y Response Objects

Aprende a crear un API con REST

20

Anatomía de una API Restful

21

Estructura de una película con Moockaru

22

Implementando un CRUD en Express.js

23

Métodos idempotentes del CRUD

24

Implementando una capa de servicios

Cómo conectarse con librerías externas en Express.js

25

Creación de una BD en MongoAtlas

26

Conexión a MongoAtlas una instancia de MongoDB

27

Conexión con Robot3T y MongoDB Compass a una BD

28

Implementación de las acciones de MongoDB

29

Conexión de nuestros servicios con MongoDB

Conoce como funcionan los Middleware en Express.js

30

¿Qué es un middleware? Capa de manejo de errores usando un middleware

31

Manejo de errores asíncronos y síncronos en Express

32

Capa de validación de datos usando un middleware

33

¿Qué es Joi y Boom?

34

Implementando Boom

35

Implementando Joi

36

Probar la validación de nuestros endpoints

37

Middlewares populares en Express.js

Implementa tests en Node.js

38

Creación de tests para nuestros endpoints

39

Creación de tests para nuestros servicios

40

Creación de tests para nuestras utilidades

41

Agregando un comando para coverage

42

Debugging e inspect

Despliega tu primera aplicación en Express.js

43

Considerando las mejores prácticas para el despliegue

44

Variables de entorno, CORS y HTTPS

45

¿Cómo implementar una capa de manejo de caché?

46

¿Cómo contener tu aplicación en Docker?

47

Despliegue en Now

Conclusiones

48

¿Qué aprendiste en este curso?

No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

¿Qué es un middleware? Capa de manejo de errores usando un middleware

30/48
Recursos

Aportes 35

Preguntas 9

Ordenar por:

Los aportes, preguntas y respuestas son vitales para aprender en comunidad. Regístrate o inicia sesión para participar.

Trabajo con Windows y tuve un ligero problema con la variable de entorno en el archivo errorHandlres.js

if(config.dev) //siempre retornaba true

Haciéndome imposible visualizar el cambio de funcionalidad, de el errorHandler, en las pruebas con postman al cambiar de entorno(dev to prod).

Resulta que en Windows ocurre lo siguiente:

// En package.json
"start": "set NODE_ENV=production && node index"

//en errorHandlers.js
console.log(process.env.NODE_ENV === 'production') //false
console.log(process.env.NODE_ENV.trim() === 'production') //true

En windows al parecer inserta caracteres especiales a la variable de entorno. Por ello, realicé los siguientes cambios:

package.json:

"dev": "set DEBUG=app:* && set NODE_ENV=development && nodemon index",

config/index.js

dev: process.env.NODE_ENV.trim() !== 'production',

Para usar el entorno de desarrollo seteé la variable de entorno “development” para que al usar trim() no me marque error por asignar un método a un undefined.

Si alguien no consigue que le salga el error capturado correctamente en modo production sólo tiene que hacer estos cambios:
package.json:
“start”: " set NODE_ENV=production && node index"

config/index.js:
dev: process.env.NODE_ENV.trim() !== ‘production’,

Mucha suerte!! 😄

El middleware es como este meme, cumple la condición o haz lo que dice el middleware y te deja pasar a la logica de la ruta. Usando next()

Dato: El orden en el que ponemos los middlewares en este caso importa muchísimo.

Estamos poniendo los middlewares de error después de las rutas porque cuando se crea el error en la ruta pasa al catch y ese catch tiene un callback next() que le pasa el error al siguiente middleware.

El siguiente middleware es logErrors que igual tiene un callback next() que le envía el error al siguiente middleware.

Podemos comprobar que si invertimos el orden de los middlewares y ponemos _errorHandler antes que logErrors en el index después de las rutas vemos que no funcionará el middleware logErrors porque el middleware errorHandler no está pasándole el error a un siguiente middleware por medio del callback next()

En Windos al parecer para ejecutar npm run start, debe ir esto en el package.json:

{
  "scripts": {
    "start": "set NODE_ENV=production&& node index"
  }
}

Middleware

Un Middleware es una capa intermedia que intercepta la información de algo, un middleware se define por defecto con una función del siguiente formato:

function (req,res,next){
	next()
}

Donde:
req es un httpRequest() con la información de la petición
res es un httpResponse() con la respuesta de la petición
next es un callback de la siguiente función a llamar

Para definir un middleware que reciba un error, sólo se le agregaría un argumento con el error

function errorHandler(err, req, res, next){
	if(err){
		res.status(err.status || 500);
		res.json({error:err})
	}
	next();
}

Seguro mis notas te ayudan a repasar todo el curso, puedes leerlas desde la comidad de tu telefono. 😄
https://github.com/JasanHdz/backendnodejs/tree/master/notes
No se rindan, éxito 💪

Utilización del middleware
Express es una infraestructura web de direccionamiento y middleware que tiene una funcionalidad mínima propia: una aplicación Express es fundamentalmente una serie de llamadas a funciones de middleware.

Las funciones de middleware son funciones que tienen acceso al objeto de solicitud (req), al objeto de respuesta (res) y a la siguiente función de middleware en el ciclo de solicitud/respuestas de la aplicación. La siguiente función de middleware se denota normalmente con una variable denominada next.

Las funciones de middleware pueden realizar las siguientes tareas:

Ejecutar cualquier código.
Realizar cambios en la solicitud y los objetos de respuesta.
Finalizar el ciclo de solicitud/respuestas.
Invocar la siguiente función de middleware en la pila.
Si la función de middleware actual no finaliza el ciclo de solicitud/respuestas, debe invocar next() para pasar el control a la siguiente función de middleware. De lo contrario, la solicitud quedará colgada.

Una aplicación Express puede utilizar los siguientes tipos de middleware:

Middleware de nivel de aplicación
Middleware de nivel de direccionador
Middleware de manejo de errores
Middleware incorporado
Middleware de terceros
Puede cargar middleware de nivel de aplicación y de nivel de direccionador con una vía de acceso de montaje opcional. También puede cargar una serie de funciones de middleware a la vez, lo que crea una subpila del sistema de middleware en un punto de montaje.

https://expressjs.com/es/guide/using-middleware.html

El orden de los middleware importa

¿el orden en como se agregan los middlewares despues de las rutas, es el orden en como se ejecutan?

En el siguiente link hay una muy buena explicación sobre el uso de los distintos middlewares en express Utilización del middleware

Si cuando corren el servidor no diferencia si está en producción o en desarrollo, veriquen su package.json. El comando ‘start’ debe estar así:

"start": "set NODE_ENV=production&&node index.js"

Nota: Esto me parece que solo funciona en Windows

Comparto por si alguno llega a tener el mismo error que yo trabajando con Windows 10.
Al definir las variables de entorno en los scripts dev y start como lo hizo el profe el programa no toma las variables, dejandolas undefined. Lo pude resolver quitando el “set” y los “&&”. Me quedaron asi:

"scripts": {
    "dev": "DEBUG=app:* NODE_ENV=development nodemon index",
    "start": "NODE_ENV=production node index"
  },

Si en la terminal te sale el siguiente error:

ReferenceError: TextEncoder is not defined

Es necesario realizar algunos cambios en el archivo encoding.js que se encuentra en la ruta node_modules>whatwg-url>dist

El cambio consiste en sustituir esto:

"use strict";
const utf8Encoder = new TextEncoder();
const utf8Decoder = new TextDecoder("utf-8", { ignoreBOM: true });

por esto:

"use strict";
var util= require('util');
const utf8Encoder = new util.TextEncoder();
const utf8Decoder = new util.TextDecoder("utf-8", { ignoreBOM: true });

Resumen de la clase

El req, res y el next lo que nos permite es que en el middleware podemos hacer cualquier ejecución de código, podemos modificar el request object o podemos modificar el response object y la manera en la que llamamos el siguiente middleware es ejecutando la funcionalidad next. Si por alguna razón le pasamos un parámetro a la funcionalidad next se ejecutan los middlewares de error.

Los middleware en next de formato error tienen una firma diferente, en vez de recibir los 3 parámetros, recibirán un 4to parámetro que será el error.

⚠️ Los middleware de error siempre tienen que ir al final de las rutas, ya que las rutas también son middlewares.

Un middleware es un bloque de código que se ejecuta entre la petición que hace el usuario (request) hasta que la petición llega al servidor.

Los que tengan Windows y tengan duda de porque ocurre el error de la variable de entorno de producción, es por la siguiente razón:
.
Al momento de escribir el comando de start, nosotros ponemos esto:

"start": SET NODE_ENV=production && node index

Hasta aquí todo bien, ¿verdad?
.
Pues, en realidad no tanto. Al escribir SET NODE_ENV=production && ... el espacio entre la palabra production y el doble ampersand (&&), Windows también lo interpreta como parte de la palabra “production”, por lo cual, es como si escribiéramos que el entorno es igual a “production” + " ", ó "production ".
.
Incluso pueden comprobarlo escribiendo el doble ampersand inmediatamente después de la palabra “production”, lo cual solucionaría el error. Quedaría de la siguiente manera:

"start": SET NODE_ENV=production&& node index

Hola, una consulta, es más recomendable utilizar

console.error(err)

para mostrar errores por consola?

Software Glue ¡¡esto es un marcador!!

El middleware de manejo de errores siempre utiliza cuatro argumentos. Debe proporcionar cuatro argumentos para identificarlo como una función de middleware de manejo de errores. Aunque no necesite utilizar el objeto next, debe especificarlo para mantener la firma. De lo contrario, el objeto next se interpretará como middleware normal y no podrá manejar errores.
https://expressjs.com/es/guide/using-middleware.html

Explicación muy muy buena de que es un middleware

Middleware de error siempre deben de ir al final de las rutas!!

Mi middleware de errorHandler() no funciona, paso un branch: https://github.com/behagoras/mongo_store/tree/errorHandler y copio el código

ErrorHandler.js

const { config } = require('../../config');

console.log('config.dev', config.dev);

function withErrorStack(error, stack) {
  if (config.dev) {
    console.log('dev = true');
    return { error, stack };
  }
  return error;
}

function logErrors(err, req, res, next) { //eslint-disable-line
  console.log('Erroring');
  console.log(withErrorStack(err.message, err.stack)); //eslint-disable-line
  next();
}

function errorHandler(err, req, res, next) { //eslint-disable-line
  res.json('erroring v2');
  console.log('erroring v2');
  res.status(err.status || 500);
  res.json(withErrorStack(err.message, err.stack));
}

module.exports = {
  logErrors,
  errorHandler,
};

index.js

const express = require('express');
const { config } = require('./config/index');
const moviesApi = require('./routes/movies');
const yearApi = require('./routes/year');
const { logErrors, errorHandler } = require('./utils/middleware/errorHandlers');

const app = express();

// body parser middleware
app.use(express.json());

yearApi(app);
moviesApi(app);

//Error middleware
app.use(logErrors);
app.use(errorHandler);

app.listen(config.port, () => {
  // eslint-disable-next-line no-console
  console.log(`Listening http://localhost:${config.port}`);
});

Los middlewares son una capa de complejidad de código que se agrega en el intermedio de otras dos capas. Se le conocer como el pegamento de código, ya que se encarga de unir dos capas.
El objetivo principal de los middlewares es corroborar que los datos que están siendo enviado de una capa hacia otra si cumplan los parámetros establecido o sean los datos correctos, de ser así, este middleware los dejara pasar de no ser así se ejecutara la acción que le indiquemos en la mayoría de los casos suele ser un error.

Me gusta así

el mayor gigachad q existe joder!

Estoy usando windows y como varios compañeros ya comentaron config.dev retorna siempre true, motivo por el cual no valide usando esto sino process.env.NODE_ENV === “development”

Genial!!

Estuve como 1 dia viendo cual era el error y solo era hacer next(err) me llevaaaaaaa jajaja

Un Middleware es una capa intermedia que intercepta la información de algo.

Para los que como yo se hayan preguntado por que la mayoría de veces el profe no usa las sentencias “if else” completas y usa solo el if

esto es por que al crear las funciones esta utilizando algo llamado “guard clauses” que nos ayudan a tener un codigo mas limpio e incluso un mejor manejo de la logica al momento de programar

Les dejo este enlace que me ayudo bastante a entender esto
https://www.laraveltip.com/deja-de-utilizar-sentencias-else-aprende-a-aplicar-guard-clauses/