Manejo de configuraciones

Python

Python siendo un lenguaje muy dinámico hace esto muy simple. Cualquier archivo es un módulo y las variables que existan dentro se pueden importar desde afuera. El módulo os contiene las utilerías necesarias para leer las variables de entorno y el lenguaje provee el resto para que todo funcione de maravilla.

Generalmente pongo este archivo en la raíz del proyecto, excepto en django donde ya tiene una ubicación particular. En django específicamente no convertiría todas las configuraciones en variables de entorno sino las que vaya necesitando.

En este código el caso especial es el segundo ejemplo, donde accedo directamente a os.environ para obtener una variable por su nombre. Esto lo haría así cuando quiera obligar a cierta variable a existir. Cosas críticas como un token pueden ser buenos candidatos, esencialmente variables sin las cuales la aplicación no pueda funcionar y para las cuales no exista un buen valor por defecto. Si la variable no existe sucederá un error de tipo KeyError y podrás en el primer arranque corregir el problema.

# /settings.py
import os

DB_NAME = os.getenv('DB_NAME', 'miapp')  # Con un valor por defecto

TOKEN = os.environ['TOKEN']  # Sin esta variable el servicio no inicia

PORT = int(os.getenv('PORT', 5000))  # Variable con un tipo de dato diferente de str

# /main.py
from settings import DB_NAME, TOKEN, PORT

print(TOKEN)

Javascript

Este también es un lenguaje dinámico (quizá demasiado) e igual no es tan difícil manejar este tipo de situaciones. Quizá la diferencia más importante es el cómo dar valores por defecto pero la estrategia no es muy diferente que en python. Lo que sí cambia es el cómo forzar a un valor a existir porque no me parece buena idea dejar un valor como undefined navegando por el código, no te dispares en el pie.

Es de notarse que estoy usando sintaxis de commonjs para los módulos. Lo haría así incluso aunque mi proyecto tenga la última sintaxis de Ecma con babeljs porque a veces querrás cargar una configuración muy pronto, antes incluso de que babel pueda interferir (me ha pasado) entonces es mejor usar una sintaxis soportada desde el principio por nodejs.

Otra cosa interesante es que esto funciona también para proyectos del frontén. Durante la compilación todas las llamadas a process.env se convierten en sus valores y así todo funciona de forma transparente.

// /settings.js

// Valor por defecto
module.exports.DB_NAME = process.env.DB_NAME || 'miapp';

// Fueza este valor a existir
module.exports.TOKEN = process.env.TOKEN || console.error('Please set TOKEN') || process.exit(1);

// Tipo de dato distinto de string
module.exports.PORT = parseInt(process.env.PORT || 5000);

// /main.js
const { DB_NAME, TOKEN, PORT } = requre('./settings');

console.log(TOKEN);

Rust

¿Creyeron que me lo iba a saltar? Pues no. Rust no es un lenguaje dinámico. De hecho es quizá el lenguaje más estático que he visto ¡todos los tipos de dato tienen que ser correctos en tiempo de compilación! Y uno se preguntaría ¿cómo le vas a hacer aquí? Bueno, yo me lo pregunté ayer y ayer mismo lo resolví.

crates.io está lleno de paquetes increíbles que hacen maravillas, y uno de ellos es lazy_static. Este paquete ofrece una macro que permite crear variables estáticas cuyo valor se define en tiempo de ejecución, y es lo que he usado para seguir mi modelo de configuración.

Este es el único caso que acabo de inventar, porque acabo de necesitar, y por ende apenas lo puse en producción en el bot de Telegram eqxbot. Rust es un lenguaje de bajo nivel que tiene más aplicaciones en otras áreas como sistemas operativos, bibliotecas, programas de línea de comandos y embebidos. En esas áreas las configuraciones quizá más bien provengan de argumentos de línea de comandos por ejemplo.

Quizá pasado el tiempo se me ocurra una mejor manera de manejar las configuraciones de mis proyectos web escritos en Rust. Me pasó por la cabeza usar argumentos de línea de comando, pero lo descarté para evitar tener una línea de comando larguísima y difícil de manejar. Además no me gustaría que los valores sensibles se guardaran en los logs de systemd.

Algo bonito de lenguajes de tipado estático es que el tipo de dato de cada configuración va a estar bien definido desde el principio.

// /src/settings.rs

use std::env;
use std::path::PathBuf;

lazy_static! {
    pub static ref DB_NAME: String = env::var("DB_NAME").unwrap_or("miapp".into());

    pub static ref TOKEN: String = env::var("TOKEN").expect("Please set TOKEN environment variable");

    pub static ref PORT: u16 = env::var("PORT").unwrap_or("8000".into()).parse().expect("Could not parse port");
}

// /src/lib.rs

#[macro_use] extern crate lazy_static;

pub mod settings;

// /src/main.rs

use miapp::settings::{ DB_NAME, TOKEN, PORT };

fn main() {
   println!("{}", DB_NAME);
   println!("{}", TOKEN);
   println!("{}", PORT);
}

Ruby

En este lenguaje soy nuevo, así que estas son solo ideas al aire, este ejemplo no lo tengo en producción. Sí manejo un proyecto ruby en producción pero ya tenían un esquema de configuración, parecido al mío pero donde sí usan un archivo config.yaml de referencia en vez de un archivo ruby. Un esquema sobrecomplicado si me preguntan.

Hay una cosa que realmente no me gusta de este lenguaje: las sentencias require y require_relative son oscuras (como las de php) pues no permiten escoger qué se importa y qué no. Entonces es difícil saber realmente de dónde viene cierto valor, clase o función. Y esto hace difícil la depuración. Dicho esto, como también es un lenguaje dinámico es fácil proceder:

# settings.rb

DB_NAME = ENV['DB_NAME'] || 'miapp'

TOKEN = ENV['TOKEN'] ? ENV['TOKEN']: (raise 'Missing token')

PORT = Integer(ENV['PORT'] || 5000)

# main.rb

require_relative 'settings'

puts DB_NAME
puts TOKEN
puts PORT

Cualquier otro lenguaje

Estas ideas son más o menos fáciles de seguir en principio en cualquier otro lenguaje. Lo más importante para mi es evitar tener un archivo config.algo y un config.algo.sample rondando por el proyecto, y que la misma sintaxis del lenguaje acompañe a la configuración. Y que la configuración se pueda leer de variables de entorno.