Módulo de configuración

Hola chicos, les quiero he notado que en la comunidad utilizando mucho los console logs para debugear, cosa que no esta mal, pero existe el debuguer de vscode que es muy bueno y pueden aprovechar el uso de los breakpoints como la consola del debuguer. Aca les dejo un link para que puedan levantar sus procesos con el debuguer del vscode. Cualquier duda, avisenme https://code.visualstudio.com/docs/nodejs/nodejs-debugging#_auto-attach-feature

Como dice el profesor, no es buena practica trackear el archivo .env, pero también es buena práctica tener un archivo .env.example que ese sí se trackea. El archivo .env.example sirve para informar qué variables de entorno el proyecto necesita (sin valores, sólo cuales son) para que personas que quieran bajarlo y correlo sepan cuales agregar.

Apuntes

Introducción

El valor de las variables de entorno (las variables de entorno son variables globales que se usan en toda la aplicación) depende de si la aplicación se ejecutara en el servidor de producción, en el de pruebas o en una versión local.

Instalación

Para manejar las variables de entorno instalaremos el modulo config propio de nest js.

npm i --save @nestjs/config

Declaración de variables entorno

Debemos listar todas las variables de entorno en un archivo llamado .env en la raíz del proyecto.

// .env
DATABASE_NAME=my_db
API_KEY='1234'

No olvides agregar este archivo en lista de los ignore de git
// .gitignore
*.env

Usar el paquete config

// src/app.module.ts
...
import { ConfigModule } from '@nestjs/config';

@Module({
  imports: [
    ConfigModule.forRoot({ // 👈 Implement ConfigModule
      envFilePath: '.env',
      isGlobal: true,
    }),
    ...
  ],
})
export class AppModule {}

Usar las variables de entorno

// src/users/services/users.service.ts
import { ConfigService } from '@nestjs/config';
...

@Injectable()
export class UsersService {
  constructor(
    private productsService: ProductsService,
    private configService: ConfigService, // 👈 inject ConfigService
  ) {}
  ...

  findAll() {
    const apiKey = this.configService.get('API_KEY'); // 👈 get API_KEY
    const dbName = this.configService.get('DATABASE_NAME');  // 👈 get DATABASE_NAME
    console.log(apiKey, dbName);
    return this.users;
  }

  ...
}

Hola 👋
Ya que no se sube el archivo .env a nuestro repositorio ni se trackea, es importante dar una documentacion de que se tiene alli pero sin especificar sus valores.
Para ellos cambiamos un poco la especificacion del .gitignore para no ignore todos los archivos terminados en .env sino solo .env

// .gitignore
# Enviroments
*.env
!.example.env

Y agregamos a la raiz un example.env donde iran las mismas variables pero sin su respectivo valor

API_KEY=
DATABASE_NAME=

Espero haberles aportado algo 🚀

profe, con esto ya puedo ser google developer expert? 😦 jaja

Hola chicos, pego las variables de entorno que tengo en un proyecto personal que estoy desarrollando, que se conecta a una base de datos y usa tokens JWT

DB_USER=...
DB_NAME=...
DB_PASS=...
DB_HOST=localhost
JWT_SECRET=hCGxxCWBpz-WhxxxumIdboco6xx...
JWT_EXPIRES_IN_SECONDS=999..

Si necesitas las variables de entorno en el app.module puedes crear una instancia, del configService, y usarlo donde necesites

const configService = new ConfigService();

Por si alguien en algún momento debe de hacer un Testing con el configModule acá esta un ejemplo, lo pongo con un guardian porque es común usar las variables de entorno para validar que un usuario haga un request con un api key adecuado y para verificar puede sacar los apikeys de las variables de entorno. Espero que les sea útil.

Guard

import {
  Injectable,
  CanActivate,
  ExecutionContext,
  UnauthorizedException,
} from '@nestjs/common';
import { ConfigService } from '@nestjs/config';

@Injectable()
export class XApiKeyGuard implements CanActivate {

  constructor(private configService: ConfigService) {  }

  canActivate(context: ExecutionContext): boolean {
    const request = context.switchToHttp().getRequest();
    const xApiKey = request.headers['x-api-key'];
    if (this.configService.get('API_KEY') !== xApiKey) {
      throw new UnauthorizedException({
        message: 'Required valid x-api-key in header',
      });
    }
    return true;
  }
}

Test

import { ConfigService } from '@nestjs/config';
import { XApiKeyGuard } from './x-api-key.guard';
const configServiceMock = {
  get: (key: string) => '1234,0000',
} as ConfigService;

describe('XApiKeyGuard', () => {
  it('should be pass guard', () => {
    const mockExecutionContext = createMock<ExecutionContext>({
      switchToHttp: () => ({
        getRequest: () => ({
          headers: { 'x-api-key': '0000' },
        }),
      }),
    });

    const guard = new XApiKeyGuard(configServiceMock);
    expect(guard.canActivate(mockExecutionContext)).toBe(true);
  });
});

Pueden ser trackeados por git, más por buenas practicas nunca deben ir al repositorio.