Desde el inicio del libro, hemos visto dos esquemas posibles para manejar las configuraciones de Laravel, mediante las variables de entorno, por ejemplo:
.env
APP_ENV=local
Y mediante los archivos de configuración que incorpora el framework, por ejemplo:
config\app.php
'env' => env('APP_ENV', 'production'),
Y cuando configuramos la caché, el correo u otro siempre mencionamos que puedes modificar uno o el otro, en este apartado, daremos algunas recomendaciones sobre cuándo debes emplear uno o el otro.
Para esto, debemos de conocer sus ventajas que automáticamente, nos trae sus carencias.
Las variables de entorno son ideales para cuando queremos probar múltiples configuraciones en un proyecto de una manera rápida, o cuando varias personas están desarrollando sobre un mismo proyecto y tienen distintas configuraciones del proyecto, en otras palabras, ofrecen un enfoque ágil y rápido para acceder a múltiples configuraciones pero esto también puede traer inconvenientes, al poder cambiar o eliminar variables de entorno por error desde un solo archivo puede traer problemas al cambiar de un modo a otro sin darse cuenta o de borrar alguna variable de entorno necesaria por el proyecto, por lo tanto, emplearla en producción pueden acarrear problemas precisamente por esta libertad.
Los archivos de configuración son excelentes para tener las configuraciones finales de producción del proyecto, por lo tanto, es donde deberíamos emplear las variables de entorno en desarrollo y en producción las configuraciones y esto es algo que ya el framework nos lo dice, ya que si vemos algunas configuraciones, veremos muchas veces un esquema como el siguiente:
config\app.php
'env' => env('APP_ENV', 'production'),
Lo que significa es que, si no existe la variable de entorno 'APP_ENV', entonces tomará la configuración el valor de 'production' que es la que tenemos que emplear en producción.
Uno de los grande problemas en el desarrollo de software que consisten en que cuando estamos desarrollando una aplicación y cada cierto tiempo vamos presentando módulos a producción, es publicar junto con estos cambios nuestras configuraciones usadas solo en desarrollo y con el esquema presentado anteriormente se puede solventar con tan solo evitar subir el archivo de .env a producción y manteniendo los valores de producción en los archivos de configuración correspondientes.
Esto no quiere decir que no es recomendable o profesional emplear variables de entorno a producción, en lo posible se debería de evitar pero, puedes emplearla con extremo cuidado, manteniendo un mínimo variables de entorno en producción que pueden ser imprescindibles para mantenerlo lo más controlado posible.
Otro buen uso de las variables de entorno en producción es cuando hacemos grandes cambios en el proyecto y lo subimos a producción o hay un error a producción que se complica repararlo mediante la visualización del log y por lo tanto, queremos probar en producción si todo lo desarrollado funciona como se espera, en estos casos, puedes descomentar las variables de entorno en producción:
.env
APP_ENV=local
APP_DEBUG=true
Probar el sistema en el servidor y cuando veamos que todo está funcionando como se espera, se vuelven a comentar:
.env
# APP_ENV=local
# APP_DEBUG=true
Y con esto, se vuelve a evitar tocar las configuraciones del proyecto que son archivos que debemos de manejar con extremo cuidado.
Es posible crear configuraciones personalizadas para nuestra aplicación, lo cual es extremadamente útil para poder personalizar estos parámetros cuando sean necesarios, por ejemplo, si quieres instalar alguna billetera electrónica como PayPal que requiere definir claves de acceso, lo más recomendado es manejar estos accesos mediante configuraciones para poder editarlas más fácilmente, también son útiles si necesitamos crear cualquier parámetro adicional para el correcto funcionamiento de la aplicación.
Para ello, debemos de seleccionar el archivo de configuración en donde queremos que esté alojada, aquí lo recomendado es que escojas el que más se asemeja segun la configuracion a crear, por ejemplo, si quieres emplear claves para acceder a Dropbox o Google Drive, puedes escoger el database.php o el de app.php si son credenciales de login social, puedes usar el de auth.php por ejemplo.
Finalmente, creamos la configuración, por ejemplo:
'app_route' => "production",
Al igual que las configuraciones existentes, es posible usar la función de ayuda env() para que tome el valor del .env si la misma existe allí:
config\app.php
'app_route' => env('APP_ROUTE', "production"),
.env
APP_ROUTE=local
Para acceder a estas configuraciones, usamos la función de ayuda config():
config('app')['env']
En la cual como primer parámetro se especifica el nombre del archivo de configuración y como siguiente parámetro la clave:
config('app')['env']
También podríamos referenciar directamente la variable de entorno:
env('APP_ROUTE', "production")
Pero si la misma no existe, pueden ocurrir excepciones y errores en el proyecto, así que, lo recomendado es que crees configuraciones personalizadas en su lugar y las consumas mediante la función de ayuda config().
En caso de que sea necesario, podemos crear archivos de configuración personalizados, simplemente debemos de crear el archivo dentro de la carpeta config del proyecto en el cual, debemos de tener la misma estructura que mantienen los actuales, por ejemplo:
config\custom.php
<?php
return [
'test_config' => env('TEST_CONFIG', 'VALUE'),
];
Y para acceder al archivo personalizado, lo hacemos de igual manera con los archivos de configuración actuales:
config('custom');
- Andrés Cruz
Este material forma parte de mi curso y libro completo; puedes adquirirlos desde el apartado de libros y/o cursos Curso y Libro Laravel 11 con Tailwind Vue 3, introducción a Jetstream Livewire e Inerta desde cero - 2024.
Desarrollo con Laravel, Django, Flask, CodeIgniter, HTML5, CSS3, MySQL, JavaScript, Vue, Android, iOS, Flutter
Acepto recibir anuncios de interes sobre este Blog.
!Cursos desde!
4$
En Academia
Ver los cursos!Libros desde!
1$
Ver los libros