¿Hay alguna ventaja (o desventaja) en usar @NestJS/Config en lugar de usar dotenv para recuperar envvar? En ambos casos, podría crear una clase que sea responsable de todos los envvars, pero ¿debería hacerlo?
Sé que @NestJS/Config usa dotenv detrás de las cortinas, pero ¿hay alguna razón por la que uno deba elegir uno sobre el otro?
Tengo entendido que usar @nestjs/config es fácil para usted administrar su configuración/envvars como un módulo en su proyecto. Por lo tanto, se puede intercambiar fácilmente en diferentes lugares:
por ejemplo, si necesita un conjunto diferente de configuración para la prueba, no tiene que modificar su proceso.env.xxx o usar un archivo .env diferente.
Sin embargo, si lo hace, requerirá que todos/la mayoría de sus otros servicios también utilicen este patrón. No sería tan útil si tiene todos sus otros servicios para ser una exportación de función pura.
Las dos grandes ventajas son la capacidad de usar Joi o class-validator o cualquier otra cosa que desee como validador de esquema para asegurarse de tener los valores de env correctos para empezar, antes de intentar acceder a ellos en tiempo de ejecución y obtener un error. Un ciclo de retroalimentación más temprano significa menos fallas más adelante. La otra gran ventaja es el uso de DI, lo que significa que es más fácil (generalmente) simular el valor de la variable env en sus casos de prueba, en lugar de tener que asignarlo a process.env en sí. También hay ligeras mejoras en la velocidad, ya que Nest almacena el valor en caché, por lo que si lo vuelve a leer, no necesita leer desde process.env , pero aparte de eso, no hay mucho que mencionar. Si no quieres usarlo, no sientas que tienes que hacerlo. También existe la desventaja de no poder usar ConfigService dentro de un decorador