Configuraciones editables por el administrador sin código complejo

Las aplicaciones se enfrentan a un problema constante. Algunas configuraciones pertenecen a un archivo .env. Otras deben poder cambiarse a través de un panel de administración sin necesidad de un nuevo despliegue de código. Algunos ejemplos incluyen nombres del sitio, zonas horarias o ajustes de registro.

Muchos desarrolladores almacenan esto en una base de datos, pero crean un caos. Terminas con dos formas de leer los datos: una parte de tu aplicación usa config() mientras que otra usa un modelo de base de datos. Esto provoca errores donde las configuraciones son inconsistentes.

Puedes evitar esto utilizando una única ruta de lectura. Trata la base de datos como una capa que se superpone a tu configuración durante el proceso de arranque (boot).

Así es como puedes construirlo:

• Usa una única fuente de verdad. La base de datos contiene el valor, pero la aplicación solo lee a través de config(). • Usa clases tipadas. En lugar de arrays sueltos, utiliza clases con tipos estrictos. Esto evita errores tipográficos y errores silenciosos. • Carga las configuraciones durante el proceso de arranque. Utiliza un service provider para extraer los valores de la base de datos e introducirlos en el array de configuración.

Ten cuidado con estas dos trampas técnicas:

1. La trampa de la zona horaria Laravel establece la zona horaria al principio del proceso de arranque. Si cambias el valor de la configuración más tarde, PHP seguirá utilizando la zona horaria antigua. Debes llamar a date_default_timezone_set() manualmente para sincronizar el ajuste global de PHP con tu nuevo valor de configuración.

2. La trampa de la instalación limpia Una aplicación nueva no tiene tablas en la base de datos. Si tu proceso de arranque falla porque falta la tabla de configuraciones, la aplicación no arrancará. No puedes ejecutar migraciones si la aplicación no logra arrancar. Envuelve tu lógica de configuración en un bloque try/catch. Esto permite que la aplicación recurra a los valores predeterminados del .env hasta que ejecutes tus migraciones.

Otro consejo de seguridad: Al desactivar una funcionalidad como el registro, no te limites a ocultar el botón en la interfaz de usuario. Elimina la funcionalidad de la configuración por completo. Si eliminas la funcionalidad de la configuración, las rutas desaparecerán. Un formulario oculto con un endpoint activo es un riesgo de seguridad. Una ruta inexistente devuelve un 404.

Mantén tu código simple. Tus controladores y vistas no deberían saber si una configuración proviene de un archivo o de una base de datos. Solo deberían ver config().

Fuente: https://dev.to/nasrulhazim/admin-editable-settings-without-giving-up-config-2cj0