Variables de ambiente en Node.js

Unit Test

💡Es el proceso de ejecutar un programa con la meta de encontrar errores. Si la “prueba” es exitosa, entonces podemos asegurar que, alguna característica o funcionalidad, fue cubierta.

.
Para este caso, sugiero que implementen sus pruebas ya sea de unit test (función o módulo) y/o end-to-end (integración).
.

Configuración

ℹ️Repositorio: link
.
Para adicionar pruebas a nuestro código utilizamos:

• jest. Engine de pruebas para JavaScript
• supertes. Handler Process para peticiones HTTP.

.
✨Como retornamos un arreglo como data para validar el cambio de pool podemos definir el siguiente bloque:

import supertest from 'supertest';
import app from '../src/index';

const request = supertest(app);

/**
 * @description colleciton of test cases on task request
 * @param {string} - case name
 */
describe('routes', () => {
    describe('GET /task', () => {
        it('should respond with a json', async () => {
            const { status, body: response } = await request.get('/task');
            expect(status).toBe(200);
            expect(Array.isArray(response.data)).toBeTruthy();
        });
    });
});

♻️Ambas librerías para pruebas, necesitamos obtener un servidor http y express no los retorna cuando utilizamos express().

import express from 'express';
import task from './routes/api/task';

// code
const app = express();

// code
app.use('/task', task);

// code
if (mode !== 'test')
    app.listen(port, () => listen(`⬢ Server Thingst - ${mode}`));
export default app;

🔥Evitamos que en test no levante el servidor, ya que supertest lo hará por nosotros.
.
♻️Actualizamos nuestro script para leer nuestros test:

"test": "NODE_ENV=test jest test/index.test.js --forceExit",

Variables de ambiente en Node.js

Las variables de entorno se utilizan para contener contenido sensible

Instalamos el siguiente paquete

Esto nos sirve para tener las variables de entorno corriendo en el proceso de node

npm i dotenv

Creamos nuestro archivo de configuracion

config>config.js

require('dotenv').config();

const config = {
  env: process.env.NODE_ENV || 'dev',
  port: process.env.PORT || 3000,
  dbUser: process.env.DB_USER,
  dbPassword: process.env.DB_PASSWORD,
  dbHost: process.env.DB_HOST,
  dbName: process.env.DB_NAME,
  dbPort: process.env.DB_PORT,
};

module.exports = { config };

Adaptamos nuestro pool

Archivo anterior

const { Pool } = require('pg');

const pool = new Pool({
  host: 'localhost',
  port: 5432,
  user: 'kevin',
  password: 'admin123',
  database: 'my_store',
});

module.exports = pool;

Archivo usando las variables de entorno

La URI se conforma por “protocolo😕/USUARIO:CONTRASEÑA@HOST:PUERTO/NOMBREDB”

El encodeURI es una manera de proteger estos datos tan sensibles, lo mismo cuando ya tenemos la URI armada

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

const USER = encodeURIComponent(config.dbUser);
const PASSWORD = encodeURIComponent(config.dbPassword);
const URI = `postgres://${USER}:${PASSWORD}@${config.dbHost}:${config.dbPort}/${config.dbName}`;

const pool = new Pool({ connectionString: URI });

module.exports = pool;

Archivo .env

	PORT=3000
  DB_USER='kevin'
  DB_PASSWORD='admin123'
  DB_HOST='localhost'
  DB_NAME='my_store'
  DB_PORT='5432'

Archivo .env.example

	PORT='',
  DB_USER='',
  DB_PASSWORD'',
  DB_HOST'',
  DB_NAME='',
  DB_PORT='',

¿Recuerdan el documento docker-compose.yml?
Pues resulta que también le podemos colocar las variables de entorno de la siguiente manera, sin configuraciones o paquetes adicionales:

version: "3.3"

services:
  postgres:
    image: postgres:13
    environment:
      - POSTGRES_DB=${DB_NAME}
      - POSTGRES_USER=${DB_USER}
      - POSTGRES_PASSWORD=${DB_PASSWORD}
    ports:
      - ${DB_PORT}:${DB_PORT}
    volumes:
      - /postgres_data:/var/lib/postgresql/data

  pgadmin:
    image: dpage/pgadmin4
    environment:
      - PGADMIN_DEFAULT_EMAIL=${PG_EMAIL}
      - PGADMIN_DEFAULT_PASSWORD=${PG_PASSWORD}
    ports:
      - ${PG_PORT}:${PG_REFPORT}

Hagan la prueba y me cuentan si funciona. 😉

Aplicando desestructuración de objetos podemos evitar repetir código.

const URI = `postgres://${USER}:${PASSWORD}@${config.dbHost}:${config.dbPort}/${config.dbName}`;

Les dejo el archivo config.js por si no quieren escribir 😃

const config = {
	env: process.env.NODE_ENV || 'dev',
	port: process.env.PORT || 3000,
	dbUser: process.env.DB_USER,
	dbPassword: process.env.DB_PASSWORD,
	dbHost: process.env.DB_HOST,
	dbPort: process.env.DB_PORT,
	dbName: process.env.DB_NAME,
};

module.exports = { config };

utilize esta extension para que se vea bonito el archivo .env
DotENV

Me siento como si estuviese construyendo Laravel desde cero pero con JavaScript. Un Taylor Otwell.

Este man sabe mucho

En config.js se tiene la configuración base para leer las variables de entorno.

En node se leen las variables de entorno con process.env.NODE_ENV seguido del entorno process.env.NODE_ENV || ‘dev’.

require('dotenv').config();

const config = {
  env: process.env.NODE_ENV || 'dev',
  port: process.env.PORT || 3000,
  dbUser: process.env.DB_USER,
  dbPassword: process.env.DB_PASSWORD,
  dbHost: process.env.DB_HOST,
  dbName: process.env.DB_NAME,
  dbPort: process.env.DB_PORT,
};

module.exports = { config };

En el archivo postgres.pool.js se trae la configuración, una configuración es no enviar variable por variable, más bien, protegerlas un poco usando encodeURIComponent() y mandar una URI con todo el esquema de conexión.

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

const USER = encodeURIComponent(config.dbUser);
const PASSWORD = encodeURIComponent(config.dbPassword);
const URI = `postgres://${USER}:${PASSWORD}@${config.dbHost}:${config.dbPort}/${config.dbName}`;

const pool = new Pool({ connectionString: URI });

module.exports = pool;

En el ambiente de desarrollo, se crea un archivo de variables de entorno .env (archivo delicado, no se sube a github), ahí se indican los datos sensibles de la BD u otras configuraciones de ejecución. Una buena practica es tener un archivo .env.example el cual indica un ejemplo de cómo deberían ir las variables de entorno.

La librería dotenv nos ayuda a leer el archivo .env . Para usarla, primero se requiere en el archivo config.js y lo que hace por defecto es leer el archivo .env y cargarlas al proceso de node.

lo más recomendado es que a su archivo postgres.js también utilicen las variables de entorno, les dejo la forma en que yo lo hice:

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

const USER = encodeURIComponent(config.dbUser);
const PASSWORD = encodeURIComponent(config.dbPassword);
const HOST = encodeURIComponent(config.dbHost);
const DATABASE = encodeURIComponent(config.dbName);
const PORT = encodeURIComponent(config.dbPort);
const URI = `postgres://${USER}:${PASSWORD}@${HOST}:${PORT}/${DATABASE}`;

async function getConnection() {
    const client = new Client({ connectionString: URI});
    await client.connect();
    return client;
}

module.exports = getConnection;

un pequeño aporte que quizas le sirva a alguno, en las variables de entorno, en el archivo .env, no se debe poner coma al final. La coma hace que node tome la variable como si la coma fuera parte de la asignación y claramente genera error

<code> 
PORT = 3000
DB_USER='juan'
DB_PASSWORD='admin123'
DB_HOST='localhost'
DB_NAME='my_store'
DB_PORT='5432'

La encodeURIComponent()función codifica un URI reemplazando cada instancia de ciertos caracteres por una, dos, tres o cuatro secuencias de escape que representan la codificación UTF-8 del carácter (solo habrá cuatro secuencias de escape para caracteres compuestos por dos caracteres “sustitutos”).

Si alguien movio su archivo .env de la carpeta raiz es posible que les tire este error al momento de hacer peticiones:

node:internal/process/promises:279
            triggerUncaughtException(err, true /* fromPromise */);
            ^

Error: getaddrinfo ENOTFOUND undefined
    at GetAddrInfoReqWrap.onlookup [as oncomplete] (node:dns:109:26) {
  errno: -3008,
  code: 'ENOTFOUND',
  syscall: 'getaddrinfo',
  hostname: 'undefined'
}

De ser asi, con regresar el archivo .env a la carpeta raiz debe volver a funcionarles correctamente.

Por si alguien no lo sabe, para que las variables de entorno tengan efecto en el código, es necesario reiniciar el servidor de node.js.

instalamos dependencias

npm install dotenv 

creamos variables de ambiente y variables de ambiente de ejemplo
.env:

PORT=3000
DB_USER='jclentino'
DB_PASSWORD='toor'
DB_HOST='localhost'
DB_NAME='my-store'
DB_PORT='5432'

.env.example:

PORT=3000
DB_USER=''
DB_PASSWORD=''
DB_HOST=''
DB_NAME=''
DB_PORT=''

creamos un objeto de configuración con las variables de entorno
config/config.js:

require('dotenv').config()

const config = {
  env: process.env.NODE_ENV || 'dev',
  port: process.env.PORT,
  dbUser: process.env.DB_USER,
  dbPassword: process.env.DB_PASSWORD,
  dbHost: process.env.DB_HOST,
  dbName: process.env.DB_NAME,
  dbPort: process.env.DB_PORT,
}

module.exports = { config }

importamos el objeto de configuración en el archivo que contiene el pool de conexiones y reemplazamos la conexión por un string de conexión
libs/postgres.pool.js:

const { Pool } = require('pg')
const { config } = require('../config/config')

const USER = encodeURIComponent(config.dbUser)
const PASSWORD = encodeURIComponent(config.dbPassword)
const URI = `postgres://${USER}:${PASSWORD}@${config.dbHost}:${config.dbPort}/${config.dbName}`

const pool = new Pool({ connectionString: URI })

module.exports = pool

corremos el proyecto

npm run dev 

si visitamos la url localhost:3000/api/v1/products/ veremos como respuesta los registros en la tabla tasks

[
  {
    "id": 1,
    "title": "Terminar curso de postgres ",
    "completed": false
  },
  {
    "id": 2,
    "title": "Limpiar ",
    "completed": false
  }
]

hola, si a alguien le aparece un error Error: getaddrinfo ENOTFOUND traten de revisar la URI o la sintaxis de nuevo
o fíjense de que {config} este desestructurado XD

Solo como comentario, crear un carpeta para un solo archivo se me hace algo innecesario, de igual forma al crearla me parece sería mejor nombrar el archivo como index.js asi los imports quedan de la misma maneta que si solo crearas el archivo config.js en raíz y son igualmente legibles y ordenados.