Este artículo es en realidad un recuerdo para el yo del futuro que olvida rápidamente algunos de los comandos más simples, por lo que he decido crear una lista de comandos de utilidad para no olvidarlos, y si de paso, esta lista te sirve a tí, entonces creo que su objetivo podría ir más lejos que solo ser una guia para mi mismo.

Esta lista empezará con pocos comandos, pero iré agregando más a medida que los recuerde. Si crees conveniente agregar algún comando a esta lista, puede dejarlo en la caja de comentarios y con gusto lo agregaremos.

Iniciar una aplicación

• npm start

Ejecuta los comando definidos en la sección scripts.start del archivo package.json

Instalar un módulo

• npm install <package-name>

Instala la última versión estable del módulo nombrado en la sección <package-name>

• npm install <pakage-name>@<version>

Igual que el anterior, con la diferencia que el parámetro version nos permite indicar la versión exacta del módulo que vamos a instalar

• npm install -g <pakage-name>

El parámetro -g instala el módulo de forma global, lo que hace disponible en cualquier desde cualquier ubicación o proyecto.

• npm install –save <pakage-name>

El parámetro --save indica que la dependencia debe de ser grabada en la sección dependenciesdel archivo package.json

• npm install -D <package-name>

El parámetro -D le indica que la librería se debe instalar en la sección devDependencies del archivo package.json

Desinstalar un módulo

• npm uninstall <package-name>

Desinstala el módulo indicado en el parámetro <pakage-name>.

• npm uninstall -g <package-name>

Igual que el anterior, con la diferencia que el parámetro -g le indica que borre la dependencia de las librerías globales.

Listar módulos globales instalados

• npm list -g –depth 0

El parámetro list es para listar todos los módulos instalados en la carpeta actual, -g complementa al comando anterior, para indicar que solo muestre los paquetes globales instalados en la carpeta del usuario.

El parámetro --depth 0 filtra las dependencias de cada paquete en la vista de árbol.

Otros tips

Establecer la variable NODE_ENV

En Windows:

• set NODE_ENV=<env>

Las variables establecidas con set solo estarán disponibles durante el tiempo de vida de la sesión, al cerrar la consola se perderá el valor.

• setx NODE_ENV <env>

El comando setx permite recordar la propiedad incluso si cerramos la consola o reiniciamos el servidor.

En Linux

• export NODE_ENV=<env>

En linux solo hay que igualar el nombre de la variable con el ambiente que decaemos establecer.

Te recomiendo que te des una venta a mi artículo Autenticación con JSON Web Tokens, el cual abordo toda la teoría, por si no estás familiarizado con el concepto de Tokens y la forma de trabajar.

Este artículo es parte de una colección de artículo en donde explico cómo Construir un API REST con NodeJS, por lo que si estas interesado puede regresar desde el comienzo.

Implementando JWT en un API REST

Lo primero será instalar el módulo de JWT, para lo cual, ejecutaremos el comando npm install –save jsonwebtoken body-parser , una vez hecho esto, tendremos que implementar un servicio de autenticación tradicional, el cual reciba usuario y contraseña y nos regrese un token en caso de éxito. El servicio quedaría de la siguiente manera:

var jwt = require('jsonwebtoken')
var bodyParser = require('body-parser')

app.use(bodyParser.urlencoded({extended: false}))
app.use(bodyParser.json({limit:'10mb'}))

app.post('/login', (req, res) => {
  var username = req.body.user
  var password = req.body.password

  if( !(username === 'oscar' && password === '1234')){
    res.status(401).send({
      error: 'usuario o contraseña inválidos'
    })
    return
  }

  var tokenData = {
    username: username
    // ANY DATA
  }

  var token = jwt.sign(tokenData, 'Secret Password', {
     expiresIn: 60 * 60 * 24 // expires in 24 hours
  })

  res.send({
    token
  })
})

La función login recibe como parámetro el usuario (req.body.user ) y el password (req.body.password ), los cuales los tendremos que validar contra nuestros usuarios, sin embargo, en este caso, para hacerlo más simple, lo hemos validado contra el usuario oscar/1234, si la autenticación falla, entonces regresamos un error al cliente. Por otra parte, si todo sale bien, creamos un token al usuario, el cual tiene una vigencia de 24 horas, para finalmente retornarlo.

Veamos un ejemplo de autenticación:

En la imagen pasada hemos enviado las credenciales correctas para que nos genere un token, sin embargo, no se puede ver correctamente debido a su longitud, es por ello que lo ponemos por a continuación:

{
"token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6Im9zY2FyIiwiaWF0IjoxNTE2MDY4OTI4LCJleHAiOjE1MTYxNTUzMjh9.zucLW085AiZ8VWojwNFFcMz0yv1H4RbeCMQy7lVjS7s"
}

Este token deberá ser guardado por el usuario para futuras invocaciones al API.

Autenticándonos mediante Tokens

El siguiente paso será crear un servicio protegido que valida la existencia del token, de lo contrario, evitará el acceso, para ello crearemos un servicio de prueba llamado secure:

app.get('/secure', (req, res) => {
    var token = req.headers['authorization']
    if(!token){
        res.status(401).send({
          error: "Es necesario el token de autenticación"
        })
        return
    }

    token = token.replace('Bearer ', '')

    jwt.verify(token, 'Secret Password', function(err, user) {
      if (err) {
        res.status(401).send({
          error: 'Token inválido'
        })
      } else {
        res.send({
          message: 'Awwwww yeah!!!!'
        })
      }
    })
})

Como podemos observar, lo primero que tenemos que hacer, es recuperar el header correspondiente al token, es decir, el token “authorization ”, si este header no se encuentra, entonces retornamos un código 401 (No autorizado) y regresamos el motivo del error.

El siguiente paso es algo confuso, pues al token hay que retirarla el substring “Baerer  “, este String es parte de las especificaciones de HTTP, y es agredo de forma automática, por lo que no entraremos en detalles, simplemente lo retiramos.

Finalmente, validamos el token mediante el método verify, el cual validará que el token sea válido y además que no esté caducado, en cualquiera de estos dos casos, un error 401 es retornado junto con el mensaje de error. Finalmente, si todo sale bien, procedemos con la operación de negocio.

El siguiente request es enviado son el header, retornando un error 401 y su mensaje de error correspondiente:

Este nuevo request es enviado con el header ‘authorization ’ el cual corresponde a un token válido generado por el servicio de login:

NOTA: Siempre será mejor usar un middleware para validar el token, de esta forma, evitamos tener que validar el token en cada invocación, sin embargo, lo hemos hecho así para hacer más fácil el ejemplo.

URL Paths

Uno de los aspectos más importantes de un servicio REST, es su URL, primero que nada, porque es la forma en que podemos consumir el servicio, pero también es importante por le da al usuario una pista significativa acerca de su funcionalidad. Una URL bien definida, podría decirle al usuario para que sirve con una precisión muy acertada, sin tener que recurrir a la documentación.

Para que una URL tenga un significado real, es necesario complementarlo con método (o verb) al que responde, pues el método nos dice el tipo de operación que va a realizar, mientras que la URL nos dice que es lo que va hacer. Analicemos las siguientes URL:

Quiero que te tomes solo un momento para analizar las URL anteriores… te aseguro que sin ser un experto pudiste adivinar con gran certeza que hace cada una de estas operaciones. Si no, te recomiendo ver la segunda parte de este artículo para refrescar un poco la memoria.

Como sea, vamos a explicar que hace cada una, en la primera URL, sabemos que el GET se utiliza para consultas y la URL habla de usuarios, luego un nombre y finalmente un avatar, por lo que podemos deducir que este servicio está realizando la consulta del Avatar del usuario oscar, ¿vez que fácil?

En la segunda URL, sabemos que PUT se utiliza para realizar updates, por lo tanto, le estamos diciendo que actualice el Avatar del usuario oscar.

En la tercera URL, sabemos que DELETE se utiliza para borrar un registro, por lo que está de más decir que lo que hace es borrar el usuario oscar.

En la cuarta URL, sabemos que POST se utiliza para crear un nuevo registro y está invocando solamente /users, esto me dice que el servicio está creando un nuevo usuario.

Con Express es realmente fácil implementar estas URL, tan solo hay que definir los Routers con el método adecuado y con el URL al que debe procesar, veamos cómo quedaría:

app.get('/users/oscar/avatar', (req, res) => {
  res.send('Hello GET:/users/oscar/avatar')
})

app.put('/users/oscar/avatar', (req, res) => {
  res.send('Hello PUT:/users/oscar/avatar')
})

app.delete('/users/oscar', (req, res) => {
  res.send('Hello DELETE:/users/oscar')
})

app.post('/users', (req, res) => {
  res.send('Hello POST:/users')
})

Los paths siempre deben de representar exactamente lo que hacen, y el método debe de corresponder con la acción que realizará, pues no hacerlo, puede confundir a los desarrolladores.

Prioridad de los paths

Un error al momento de iniciar con Express es pensar que el orden en que se definen los Routers es irrelevante, como si de una función se tratara, la cual puede ser llamada desde donde sea y siempre se ejecuta la correcta, sin embargo, esto no es cierto. Por este motivo, Express evaluar los Router en el orden en que están definidos.

Existe ocasiones en que más de una URL puede colisionar y entrar en el Path equivocado, por ejemplo, las siguientes dos URL:

GET: /*

GET:/login

La primera acepta cualquier URL, porque tiene un comodín (*), mientras que la segunda, solo acepta la URL /login. En este caso, como /* esta primero, entonces atenderá las peticiones que lleguen a /login, porque el path /* cumple con el patrón, en tal caso, tendríamos que invertir el orden de los Routers de la siguiente manera:

GET:/login

GET: /*

De esta forma, cuando llegue una petición a /login, la tomará el primer Router y para todos los demás path será /* quien procese la solicitud.

URL Params

Una de las características de REST, es la posibilidad de convertir ciertas partes de una URL en parámetro, de tal forma que nos ahorra tener que escribir una URL para cada registro que necesitemos.

Regresando al ejemplo de los servicios para usuarios GET: /users/oscar, podemos apreciar que “oscar” esta fija en la URL, lo que provocaría que tuviéramos que tener un Router para cada usuario registrado. Por suerte, Express nos permite escribir URL Params. Para convertir una sección de la URL en URL param, solo tendremos que anteponer dos puntos (:) antes, por ejemplo:

/users/:username

/users/:username/:field

En la primera URL podríamos recibir consultas para todos los usuarios, por ejemplo:

/users/oscar , /users/juan , /users/pedro

Mientras que en la segunda URL podríamos consultar cualquier campo del usuario, por ejemplo:

/users/oscar/avatar  o /users/juan/banner

Para recuperar los URL Params, tan solo es necesario recuperarlos del objeto request de la siguiente manera: req.params.<name>. Veamos algunos ejemplos:

Query params

Los query params son lo más conocidas, y son todos aquellos que van al final de la URL seguido del símbolo de interrogación (?). Se pueden enviar cuantos Query params se requiere, siempre y cuando no excedamos el límite máximo de caracteres para un URL. Cada parámetro deberá está separado un el símbolo de ampersand (&). Algunos ejemplos:

/cources?coupon=FREE&Source=Google

Este tipo de parámetros es muy común en campañas publicitarias, pues el param coupon determina que el curso a comprar es gratis (free), mientras que el param Source nos dice de donde llego el cliente (google).

Para recuperar un Query param en Express se usa la siguiente sentencia, req.query.<parama-name>. Veamos cómo implementarlo en Express.

app.get('/cources', (req, res) => {
  var coupon = req.query.coupon
  var source = req.query.source
  res.send("Coupo: " + coupon + ", Source: " + source)
})

Si ejecutamos la URL /cources?coupon=FREE&Source=Google  obtendremos el siguiente resultado:

Body params

El tercer y último tipo de parámetro que podemos enviarle a un servicio REST, es el payload (o body), el cual puede ser un mensaje largo que no se puede ver a simple vista. No todos los métodos HTTP soportan el envío de un payload, por lo que hay que tener eso en cuenta.

De los métodos más utilizados que soportan el envío de un payload son: POST, PUT, PATCH, DELETE. Observa que el método GET no lo soporta.

Recuperar el body del request no está simple como parecería, pues en realidad, este parámetro es un InputStream, lo que quiere decir, que se recibe como los datos poco a poco y no todo de una. Esto nos obliga a procesar el payload a medida que va llegando. Este proceso lo podemos simplificar con ayuda del módulo body-parser, el cual instalamos en la primera parte de este artículo (npm install –save body-parser).

Mediante este módulo, es posible convertir el payload en varios formatos, pero el que nos interesa es JSON, pues es el estándar para REST. Configurarlo, solo tendremos que importarlo y agregar un middleware (los analizaremos más adelante).

Finalmente, existe una última forma de recibir información para el API, la cual es a través de Header, sin embargo, esta parte la dejaremos para la siguiente parte, en la cual hablaremos de la autenticación mediante JSON Web Tokens (JWT).

También puedes ver como implementar los verbs con Java en mi guía de implementación de un API REST con Java.

Verbs

Uno de los conceptos más importantes cuando trabajamos con REST, son los Verbs (o también llamados métodos), los cuales conocemos como GET, POST, DELETE, PATCH, PULL, etc. determinan la acción que deseamos hacer sobre un determinado recurso. En REST, cada método tiene un significado para el API, pues una misma URL puede tener diferente significado dependiendo sobre el método se ejecutó.

Por ejemplo, la URL /user/oscar sobre el método GET, representa una consulta para el API, mientras que la misma URL sobre el método DELETE, representa una instrucción de borrar al usuario.

Los métodos (o verbs) más utilizados en un API REST son:

• GET: Se utiliza para realiza consultas (Select)
• POST: Se utiliza para crear nuevos registros (Insert)
• DELETE: Se utiliza para borrar un registro (Delete)
• PUT: Se utiliza para actualizar total o parcialmente un registro existente (Update)
• PATCH: Se utiliza para actualiza solo una pequeña parte de un registro existente (Update)

Puedes ver la lista completa de método soportados en la siguiente en la documentación oficial de Express.

Utilizando los verbs con Express

En express es realmente fácil crear servicio que atienda peticiones en los diferentes métodos, ya que proporciona una función para cada uno de ellos, el cual se define de la siguiente manera:

express.<verb>(<path>, <callback>)

El <verb> representa el método HTTP soportado por express en minúscula, el <path> es la ruta en la cual escucha las peticiones y el <callback> es la función que procesará las peticiones, la cual recibe dos parámetros, el primero es un objeto que representa el request y el segundo es el objeto que representa la respuesta, por ejemplo:

var express = require('express')
var http = require('http')
var app = express()

var users = ['oscar', 'juan', 'marcos']

app.get('/users', (req, res) => {
  res.send(users)
})

app.get('/', (req, res) => {
  res.status(200).send("Welcome to API REST")
})

http.createServer(app).listen(8001, () => {
  console.log('Server started at http://localhost:8001');
});

Veamos las líneas 5 y 9, hemos definido dos Routers, los cuales atienden peticiones GET, sin embargo, las dos atienden en diferente path, por lo que si ejecutamos la URL http://localhost:8001/users tendremos un resultado diferente que ejecutar simplemente http://localhost:8001.

Al igual que tenemos Router para procesar peticiones GET, podemos agregar otros métodos, como, por ejemplo:

app.post('/users', (req, res) => {
  users.push('User ' + users.length)
  res.send("New user add")
})

Este nuevo Router atiende peticiones POST en el path /users, y tiene como funcionalidad agregar un nuevo usuario a la lista actual de usuario y retorna un mensaje al cliente. Desde luego que este servicio no lo podemos probar desde el navegador, por lo que utilizaremos el plugin Restlet de Chrome para probarlo, el resultado es el siguiente:

De esta forma, podemos agregar tantos métodos necesitemos para nuestra API, por ejemplo:

app.patch('/users',(req, res) => {
  res.send('PATCH method')
})

app.delete('/users',(req, res) => {
  res.send('DELETE method')
})

Como hemos visto hasta ahora, es posible definir una serie de Router capaces de atender en los diferentes métodos que ofrece Express, también hemos visto que es posible definir más de un Router con el mismo método para atender diferentes URL.

En la siguiente parte de este artículo hablaremos acerca de los paths y como parametrizarlos para atender en URL dinámicas.

Continuación (Tercera parte)

Si no sabes muy bien que es un API REST, te invito a que veas mi video un Youtube donde lo explico “Qué es API REST? – 🚀Y por que es importante aprenderlo 🚀”

Construir un API REST es realmente simple, y más aún, si cuentas con las tecnologías adecuadas. En este sentido, NodeJS + Express, se ha convertido en la combinación perfecta para realizar esta tarea, pues es posible construir y levantar un API REST en cuestión de segundos.

Preparando el proyecto

Lo primero será crear un nuevo proyecto desde el cual estaremos trabajando, para ello, crearemos una nueva carpeta en cualquier parte y nos ubicaremos en ella a por medio de la línea de comandos. Una vez allí, ejecutaremos el comando npm init , el cual nos solicitará algunos datos referentes al proyecto, al finalizar, nos habrá creado el archivo package.json y una carpeta llamada node_modules, la cual contiene todas las librerías estándar de NodeJS.

En este punto, tendremos que instalar los módulos de NPM que vamos a requerir, para ello, ejecutaremos los comandos:

• npm install –save express
• npm install –save body-parser

Express es el módulo más popular para desarrollos web en NodeJS y además, es especialmente útil para la construcción de API’s, por otra parte, el Middleware body-parse, que anteriormente era parte de Express, nos ayudará a procesar el payload (o body) del request, el cual nos lo dejar listo y en el formato que lo necesitamos, en este caso, en JSON.

En este punto, tendremos un archivo package.json  muy parecido al siguiente:

{
  "name": "api-rest",
  "version": "1.0.0",
  "description": "Mi primer API REST",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [
    "API",
    "REST",
    "NodeJS"
  ],
  "author": "Oscar Blancarte",
  "license": "ISC",
  "dependencies": {
    "body-parser": "^1.18.2",
    "express": "^4.16.2"
  }
}

Levantando un servidor

El siguiente paso será montar un servidor usando NodeJS + Express, para lo cual, tendremos que crear un nuevo archivo llamado server.js  directamente sobre la raíz del proyecto, el cual se verá de la siguiente manera:

var express = require('express')
var http = require('http')
var app = express()

app.get('/', (req, res) => {
  res.status(200).send("Welcome to API REST")
})

http.createServer(app).listen(8001, () => {
  console.log('Server started at http://localhost:8001');
});

Con estas simples líneas, hemos creado un servidor web capaz de servir peticiones web, sobre el cual montaremos nuestra API REST. Antes de ejecutar este código, vamos a analizar qué está pasando. Lo primero que podemos apreciar, es que importamos el módulo Express del que ya hablamos y el módulo Http, el cual es parte del estándar NodeJS, por lo que hace falta instalarlo con NPM. Este segundo módulo es utiliza para crear oyentes capases de escuchar peticiones HTTP en un determinado puerto. El segundo paso será crear una instancia de Express, como podemos observar en la línea 3.

Una vez hechos con la instancia de Express, solo nos resta crear los Routers, los cuales son las reglas por medio de las cuales Express sabrá como procesar las diferentes peticiones en diferentes URL’s, para lo cual, Express proporcionar una serie de funciones para procesar los diferentes métodos que soporta HTTP, como es GET, POST, DELETE, PUT, etc. En este caso, hemos creado un router para atender las peticiones que lleguen a la raíz del servidor. Es por eso la importancia de la línea 5, la cual responderá con la frase “Welcome to API REST” al recibir una petición GET a la raíz del servidor.

Al igual que tenemos la función GET, tenemos todas las demás, por ejemplo, POST, DELETE, PUSH, PUT, etc. las cuales se definen de la misma forma que GET, pero solo es necesario cambiar la función con la del método HTTP deseado, por ejemplo: app.post(), app.delete(), app.push(), app.put(). Todas estas variantes, reciben dos parámetros, el primero es la URL en la cual responden y el segundo es una función (Callback) la cual será ejecutada una vez que una petición sea recibida.

Finalmente, y una vez que tenemos todas las reglas de routeo (routers), tendremos que crear un oyente para recibir las peticiones, para ello nos apoyamos del módulo Http como podemos ver en la línea 9. El server Http lo creamos (createServer) pasando como parámetro la instancia de Express para finalmente levantar el servidor con la función listener. Esta última, recibe el puerto en el que escucha y una callback que se ejecuta una vez levantado el server.

Probando el servidor

Una vez que tenemos una primera versión de nuestro servidor, solo nos queda probarla para asegurarnos de que todo funciona bien, por lo cual, regresamos la línea de comandos y ejecutamos node server.js , como resultado tendremos lo siguiente:

Una vez tenemos la confirmación de que nuestro server esta arriba, procedemos con probarlo con el navegador, por lo que entramos a la URL http://localhost:8001 y veremos el siguiente resultado:

Si ves esto, es porque nuestro servidor ya está listo. No es gran cosa, pero al menos ya es avance para construir nuestra API REST.

Ya con esto, tenemos todo preparado para iniciar con la construcción de nuestros servicios, pero esto lo dejaremos para la segunda parte de este artículo.

Continuación (Segunda parte)

Que es un Token

Lo primero que debemos de entender, es que es un token, pues será un concepto fundamental para entender el resto del artículo.

Un token es una cadena alfanumérica con caracteres aparentemente aleatorios, como el siguiente:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

o el siguiente:

24353689

Estas cadenas de texto, pueden no aparentar un significado, sin embargo, tiene un significado real para el servidor o institución que lo emitió, el cual puede entender y así, validar al usuario que intenta acceder a la información, e incluso, puede tener datos adicionales.

Te dejo un video donde explico que es un Token:

Un caso simple de tokens, es el dispositivo que dan los bancos para realizar transacciones desde internet, este token te genera un valor numérico que luego tenemos que ingresar al sistema, para que de esta forma, el portal pueda asegurarse de que efectivamente somos nosotros y no un impostor.

En el caso de los tokens bancarios, no se almacena una información real dentro del Token, sino que simplemente es un valor generado que luego puede ser validado por el banco como un valor real generado por nuestro token. Sin embargo, con JWT podemos enviar cualquier dato del cliente dentro del token para que el servidor pueda obtener mucha más información de nosotros.

Que son los JSON Web Tokens

Bien, una vez que comprendemos que son los Tokens podemos decir que los JWT son un tipo de token el cual engloba una estructura, la cual puede ser desencriptada por el servidor y de esta forma, autenticarnos como usuario en la aplicación.

Veamos la estructura de un JWT:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

Observemos que la cadena está dividida en 3 secciones separadas por un punto. Estas tres secciones tienen un significado:

1. HEADER: la primera parte, corresponde a los Header, y se almacena por lo general el tipo de token y el algoritmo de encriptamiento.
2. PAYLOAD: La segunda parte, contiene los datos que identifican al usuario, como puede ser su ID, nombre de usuario, etc.
3. FIRMA: La tercera parte es la firma digital, la cual se genera con las secciones anteriores y sirve para validar que el contenido no haya sido alterado.

Ejemplo del Header

{
  "alg": "HS256",
  "typ": "JWT"
}

Ejemplo del Payload

{
  "id": "1234567890",
  "name": "Oscar Blancarte",
  "rol": “admin”
}

La firma por otra parte es el header y el payload en base64 y después encriptado.

Puedes leer más de JWT en su página oficial

Como se utiliza los JWT

Como ya hablamos, los JWT se utilizan para autenticar a los usuarios, para ello, el usuario requiere de un login tradicional como es el usuario y password. Una vez, que el sistema de Backend valida que el usuario y contraseña son correctos, este retorna un token al usuario. Este token lo deberá guardar el cliente, pues de aquí en adelante, todas las peticiones que realice al servidor, deberá llevar el token.

El token es por lo general almacenado en Cookies o en el LocalStorage del navegador, y cuando es requerido enviar un request al servidor, se recupere y se envía como header.

Un dato interesante del token es que no requiere que el servidor lo almacene para compararlos cuando lo envíe el cliente, pues el token por si solo puede ser auto validado, y como tiene un payload, es posible determinar de quien es el token. Veamos el siguiente payload:

{
  “userID”: 12345,
  “username”: “oblancarte”,
  “rol”: “admin”
}

Cuando el servidor desencripte el token, podrá recuperar este payload y con ello, podrá saber que usuario es e incluso, es posible guardar datos adicionales como el rol o cualquier dato en formato JSON.

Otro dato interesante del token es que expira, es decir, el token solo es válido por un tiempo determinado. Por lo que el usuario deberá volverse a logear una vez que el token expire.

Veamos cómo funcionaría todo el ciclo de vida de un JWT

Ya hemos hablado de como JWT funciona, pero ahora entraremos a ver como es la interacción que tiene un usuario al autenticarse por medio de JWT, para lo cual veamos la siguiente imagen:

Los pasos son los siguientes:

1. El usuario requiere de una autenticación tradicional con el servidor, es decir usuario y password (o cualquier otro tipo de autenticación).
2. El servidor validará que los datos introducidos sean correctos y generará un Token.
3. El servidor enviará el token al usuario y este lo tendrá que almacenar de cualquier forma.
4. Una vez con el token, el usuario realiza una petición al servidor, enviando en el header el token previamente generado.
5. El servidor validará que el token sea correcto, desencriptandolo mediante la misma llave que utilizo para encriptarlo.
6. Si el token es correcto, entonces el servidor retornará los datos solicitados.

Cabe mencionar que los puntos 4,5 y 6 se pueden repetir indeterminado número de veces hasta que el token caduque, cuando esto pase, entonces será necesario reiniciar desde el paso 1.

Como implementar un JWT

Existe una serie de librerías que nos permite crear un JWT, y todo dependerá del lenguaje que utilicemos. Sin embargo, quiero mostrarte como crear un JWT con NodeJS.

Lo primero, es que será necesario importar el módulo jsonwebtoken:

npm install –save jsonwebtoken

Generación del Token

ya con la dependencia instalada podemos crear el token de la siguiente manera:

var jwt = require('jsonwebtoken')

function generateToken(user) {
  var u = {
   username: user.username,
   id: user.id
  }
  return token = jwt.sign(u, ‘password’, {
     expiresIn: 60 * 60 * 24 // expires in 24 hours
  })
}

Lo primero que haremos será crear una función que reciba el objeto usuario o cualquier otro objeto que contenga la información requerida para la autenticación. Luego mediante el objeto usuario, creamos el objeto u, el cual solo contiene el username y el ID del usuario. Este objeto se convertirá en el payload del JWT, es decir la segunda parte del token.

Seguido, procedemos a crear el token mediante el módulo jwt, el cual nos proporciona el método sign que recibirá el payload y un password, este password deberá ser secreto, pues con él, podremos crear y desencriptar los tokens. Finalmente, el tercer parámetro son las opciones, aquí podremos seleccionar el algoritmo de encriptación, la fecha de expiración, etc.  En este ejemplo dejamos la configuración por default, pero agregamos que el token sea válidos solo por 24 horas.

Finalmente, el token es retornado al cliente.

Validación del token

Hasta este punto solo hemos visto la parte de la generación del Token, pero falta la segunda parte, en donde tenemos que validar que el Token que el cliente nos manda, es válido.

Para validar el Token podemos utilizar un Middleware de Express que valide de forma automática todas las URL que inicien con /secure. El middleware se ve de la siguiente manera:

router.use('/secure',function(req, res, next) {
  var token = req.headers['authorization']
  if (!token) {
    res.status(401).send({
      ok: false,
      message: 'Toket inválido'
    })
  }

  token = token.replace('Bearer ', '')

  jwt.verify(token, ‘password’, function(err, token) {
    if (err) {
      return res.status(401).send({
        ok: false,
        message: 'Toket inválido'
      });
    } else {
      req.token = token
      next()
    }
  });
});

Podemos ver que en la primera llínea inicializa el middleware, luego en la segunda línea obtenemos el token del header “authorization”. Si el token es Null regresamos un 401 indicando que no el cliente no tiene privilegios.

Los token generados por JWT se crean con la palabra “Bearer” al inicio del token, por lo que en la línea 10 quitamos esa parte del token, seguido, en la línea 12 realizamos la validación del token mediante el método verify.

Este método recibe el token como primer parámetro, como segundo parámetro, mandamos el password para desencriptar el token. Finalmente se envía como tercer parámetro una función Callback una vez que el token sea validado.

Si todo salió bien, el token estará en la variable token, en caso contrario, tendremos el error en la variable err.

Conclusiones

Como pudimos ver, los tokens son una magnifica forma de administrar la autenticación de los usuarios, pues permite crear de forma fácil, un mecanismo para comunicarse de forma segura entre el cliente y el servidor, además, de que permite mantener autenticado a un usuario por un tiempo determinado, evitando tener que iniciar sesión cada vez que entre a nuestra aplicación.

NodeJS es básicamente un entorno de ejecución JavaScript del lado del servidor, puede sonar extraño, ¿JavaScript del lado del servidor? ¿Pero que no JavaScript se ejecuta en el navegador del lado del cliente? JavaScript nace inicialmente en la década de los noventas por los desarrolladores de Netscape, el cual fue creado para resolver problemas simples como validación de formularios, alertas y alguna que otra pequeña lógica de programación, nada complicado, sin embargo, JavaScript ha venido evolucionando hasta convertirse en un lenguaje de programación completo. NodeJS es creado por Ryan Lienhart Dahl, quien tuve la gran idea de tomar el motor de JavaScript de Google Chrome llamado V8, y montarlo como el Core de NodeJS.

Como puedes ver en la imagen, NodeJS es en realidad el motor de JavaScript V8 con una capa superior de librerías de NodeJS, las cuales se encargan de la comunicación entre el API de NodeJS y el Motor V8. Adicionalmente, se apoya de la librería Libuv la cual es utilizada para el procesamiento de entradas y salidas asíncronas.

Cabe mencionar que NodeJS es Open Source y multiplataforma, lo que le ha ayudado a ganar terrenos rápidamente.

Que es NodeJS (Según su creador):

Node.js® es un entorno de ejecución para JavaScript construido con el motor de JavaScript V8 de Chrome. Node.js usa un modelo de operaciones E/S sin bloqueo y orientado a eventos, que lo hace liviano y eficiente. El ecosistema de paquetes de Node.js, npm, es el ecosistema más grande de librerías de código abierto en el mundo.

Te puede interesar mi articulo sobre las 10 tecnologías que debes aprender, en donde incluyo a NodeJS.

NodeJS un cambio de paradigma

NodeJS ha representado para muchos programadores todo un cambio de paradigma, pues tiene como principal característica, el procesamiento asíncrono en casi la totalidad de sus tareas. Para ello, NodeJS utiliza únicamente un hilo de ejecución y procesamiento de entrada y salida asíncrono. Con lo cual, NodeJS no realiza bloqueos en el procesamiento.

Esto quiere decir que cuando es requerido realizar una tarea secuencial, la cual requiere realizar el paso 1,2 y 3 en ese orden, es necesario crear una serie de callbacks, lo cual es básicamente que al terminar el paso 1, manda llamar una función correspondiente al paso 2, y al terminar el paso 2, manda llamar otra función correspondiente al paso 3. Esta serie de llamadas o callbacks es una de las cuestiones más criticadas de NodeJS, que incluso, ya le han puesto un nombre Call Backs Hell o el Infierno de las call backs, pues es necesario anidar una gran cantidad de funciones para realizar una única operación, lo cual puede ser un verdadero dolor de cabeza al intentar seguir el código, además que es muy verboso.

Como podemos ver en la imagen, el resultado de la ejecución de cada paso es enviado a la siguiente función (Callback) para continuar con el procesamiento.

La pregunta obvia aquí es, si es tan complicado usar callback ¿porque no procesamos todo de forma síncrona?, pues la respuesta es muy simple, y es que JavaScript funciona nativamente de forma asíncrona y segunda, esta es en realidad uno de los principales diferenciadores de NodeJS, pues trabajar de esta forma ayuda a optimizar los recursos del servidor, pues no mantiene hilos bloqueantes entre la ejecución de cada paso.

NodeJS y la arquitectura de Microservicios

Para los que no conozcan esta arquitectura, le comento que microservicios es una arquitectura que promueve el desarrollo de pequeñas aplicaciones que corran de forma independiente, en lugar de tener aplicaciones monolíticas montadas en un servidor de aplicaciones, en donde si un servidor se muere, probablemente dejen de funcionar muchas aplicaciones.

NodeJS tiene la gran característica de ser extremadamente modular, esto quiere decir que existe un pequeñísimo módulo para cada característica de NodeJS, por ejemplo, existe un módulo para usar el File System, otro para parciar el body de un request http, otro para conexión base de datos. Es más, existe módulos que solo tiene una función. Esto ayuda a que las aplicaciones NodeJS corran únicamente con los módulos estrictamente necesarios y ayudan en gran parte a crear aplicaciones mucho más livianas.

Dada la modularidad y simplicidad de trabajo de JavaScript, hace que NodeJS esté tomando mucho terreno en el desarrollo de aplicaciones simples, que pueden ser montados en servidores de hasta 5 USD al mes, y funcione a la perfección.

NodeJS y NPM

Para los que viene de Java, NPM es el equivalente a Maven, si, aun así, no te queda claro. NPM es el gestor de paquetes (módulos) de NodeJS, mediante NPM es posible descargar de forma automática las dependencias y ejecutar instrucciones como iniciar o apagar NodeJS.

NPM o Node Package Manager es en realidad mucho más complejo de lo que acabo de decir, pero lo quería resumir en pocas palabras. Puedes leer más de NPM aquí.

Ventajas y desventajas de NodeJS

Hasta este momento, solo le hemos echado flores a NodeJS, pero es hora de poner las cosas en perspectiva y analizar las cosas buenas y malas que tiene, para de esta forma poder tener un mejor análisis.

*Cabe mencionar que este análisis es desde mi muy humilde punto de vista, y puede que para algunos la desventaja sean ventajas y viceversa. Pero como dicen, no hay más ciego que el que no quiere ver, por lo que si tú eres un apasionado purista de NodeJS puede que nada de esto te parezca.

Ventajas

• OpenSource: sin duda, hoy el software open source ha tenido la evolución más rápida y con mejor aceptación de los usuarios, además que es totalmente gratis su uso, puede descargar el código fuente para analizarlo y crear tu propio proyecto de Open Source basado en este.
• Optimización de los recursos: Dada la naturaleza asíncrona de NodeJS nos permite tener una mucho mejor administración de los recursos.
• Desarrollo agiles: NodeJS permite crear aplicaciones de una forma simple y rápida, a diferencia de otros lenguajes de programación como Java o C#, que se requiere de una gran cantidad de clases para echar a volar un proyecto.
• FullStack: Dado que JavaScript se puede ejecutar del lado del servidor y del cliente, es posible crear aplicaciones de BackEnd y FrontEnd con una sola tecnología.
• Modularidad: Como ya lo hablamos, NodeJS es extremadamente modular, lo cual permite utilizar únicamente los módulos requeridos sin traernos nada de más.

Desventajas:

• Tipos dinámicos: JavaScript permite enviar como parámetro un objeto que no tiene definición, solo abres y cierres llaves {} y dentro pones lo que sea, lo que hace muy complicado saber que valores puedes enviar. Si eres programador JavaScript seguramente me quedarás colgar vivo diciendo que eso es bueno.
• Callbacks: Si bien, como ya analizamos, esto hace que se utilicen mejor los recursos, la verdad es que las callbacks son un dolor de cabeza, ya que tener funciones para cada paso es incómodo y hace muy complicado seguir el código.
• Refactor: Si alguna vez has hecho un refactor importante en un proyecto de JavaScript seguro me entenderás, pues casi nunca es posible realizar uno de forma segura, pues el tipeado débil y tipos dinámicos hacen que sea complicado para el IDE determinar cómo refactorizar.
• Librerías estándar: Esta es a mi ver una de las más fuertes, es verdad que existen librerías para todos los problemas que se te puedan ocurrir, pero el problema es que existen muchas opciones para lo mismo, haciendo complicado elegir entre una u otra. Adicional que cada una avanza a un ritmo separado en vez de unir fuerzas para mejorar una versión estándar.
• Arquitectura: En mi experiencia las aplicaciones NodeJS tiene un nivel de arquitectura muy por debajo de los lenguajes de programación tradicional como Java o C# pues en NodeJS todo se basa en funciones que son enviadas y exportadas de clases. Y es raro ver que se implementan patrones arquitectónicos o patrones de diseño (desde mi experiencia).

Conclusiones

A mi ver NodeJS es sin duda una de las tecnologías más prometedoras del futuro, dado que JavaScript se está convirtiendo en el lenguaje de programación rey. No me extrañaría que JavaScript termine desplazando a lenguajes como Java o C#, un que para esto falta tiempo.

Creo que empezar a apostar por NodeJS en este momento puede ser una muy buena inversión, pues cada vez empezaremos a ver más y más proyectos desarrollados con NodeJS y estas aplicaciones necesitarán de desarrolladores.