Quizá faltaba un poco de contexto en la publicación anterior (si no la has leído este es el momento). La motivación para escribir esta entrada es un comentario muy acertado de Federico Mena, quien aportó sobre lo engorroso que resulta ver un traceback en los registros de un servicio, aunque vaya acompañado con un mensaje como se te olvidó establecer esta variable de entorno necesaria. En realidad su comentario me puso a pensar lo ciego que fui al plantear con tanta seguridad un esquema que de ninguna manera puede ser la regla, y me permitió ver y criticar mi propuesta desde otras perspectivas en las que encajaría más como problema que como solución.
Cuándo sí
El contexto al que mi propuesta del manejo de configuraciones está dirigido es al de los servicios que desarrollo. Generalmente son servicios propietarios (código cerrado) y existe solamente un ambiente de producción, acompañado quizá de un staging o un desarrollo pero no muchísimos más. En este contexto también la cantidad de ojos sobre el código es limitada y el conocimiento que del proyecto tiene cada par de ojos es amplio. En estas circunstancias encontrar un traceback al iniciar el servicio no es necesariamente la más terrible de las condenas. También no es algo que pasaría muy seguido. Solamente al iniciar por primera vez un servicio en un lugar, ya sea entorno local o servidor.
Bajo estas circunstancias me permito sopesar el manejo adecuado del error ocasionado por la falta de alguna variable de entorno contra el costo de mantener una dependencia adicional en el proyecto. Mientras que el primero sucede en un momento donde será fácil corregir (durante el primer inicio de un servicio en un entorno) y en la práctica escaso, el segundo añade piezas móviles al sistema. Mecanismos con más piezas tienen más puntos de quiebre.
Cuándo no
Aunque Federico no lo mencionara, me puse a pensar y encontré exactamente en qué escenarios el esquema de configuración que propongo no puede ser la norma. Todo el tiempo estuvo frente a mis narices y lo pasé de largo ¿Cómo pude ser tan ciego?
Se trata del software que se distribuye, el software que se usa en más de un servidor. Ya sea libre o propietario, un servicio que se distribuye será instalado en decenas, centenas o miles de servidores por personas con diferentes trasfondos. En este escenario tener un traceback en los registros sí es un calvario al que no deberíamos someter a los usuarios y una buena estrategia para el manejo de las configuraciones será deseable. Aquí no recomendaría mi propuesta.
En estos escenarios lo que se hace (desde los tiempos de las primeras canciones) es tener en efecto un archivo de configuración, digamos /et/myservice/myservice.conf, en algún formato de elección de quien desarrolló el servicio. Al iniciar el servicio se indica la ubicación del archivo de configuraciones y si existe algún problema se notifica al arranque, de preferencia de la forma más fácil de entender posible para que el error se pueda corregir de la mejor manera. Ya sea un error de sintaxis o una incongruencia gramática.
A estas alturas valdría la pena mencionar qué motivó la publicación original. Se trata de este hilo:
Ni uno ni otro. Contrapropuesta: un archivo en el lenguaje de programación de elección que exporta variables que leen su valor del entorno (algunas con un valor por defecto) https://t.co/8XUylpc7as
— unsigned double long long long (@categulario) September 20, 2020
Si el escenario es un servicio que se distribuye, entonces definitivamente habría que escoger algún lenguaje para establecer estas configuraciones, y tener una buena estrategia para validarlo. Usar el mismo lenguaje que esté usando el proyecto sería posible, pero seguramente no deseable hasta por motivos de seguridad.
¿Y tú qué prefieres?
Cuando haga un servicio que se distribuya a muchos usuarios mi elección probablemente va a ser .toml o .ini. Son formatos increíblemente sencillos con la expresividad suficiente para la mayoría de los casos, y el segundo de ellos lleva además mucho tiempo circulando, es bien conocido y bien soportado.
Ni json ni yaml (y de paso tampoco xml) me parecen elecciones razonables por la misma razón por la que mi propuesta no aplica. Hay que ofrecer un lenguaje sencillo y expresivo para que quien lo use no tenga que romperse la cabeza escribiéndolo, y que no sea fácil de romper.
Claro que las necesidades de cada proyecto son diferentes, y a veces incluso lenguajes propios como el que usa nginx pueden añadir la expresividad necesaria sin hacerlo todo innecesariamente complicado.