Por qué hay que usar la facade de Storage de Laravel

Algo que suelo ver en gente que está empezando a trabajar con Laravel es que se lían un poco entre usar la función asset(), url(), public_path o Storage::url() para cargar los recursos. ¡He visto de todo!

Normalmente, cuando trabajamos en local con subida de ficheros, pondremos nuestra variable de entorno FILESYSTEM_DISK=public. Esto hará que nuestros ficheros se suban a la carpeta storage/app/public y, junto con el enlace simbólico que nos da php artisan storage:link, estos ficheros podrán ser accesibles públicamente.

Mientras programamos en local, erróneamente podemos ver que si ejecutamos la función asset('storage/' . $filePath) o public_path('storage/' . $filePath) nos cargará correctamente el fichero. Y es verdad, funciona perfectamente!. En local.

Normalmente, al hacer un deploy a producción solemos usar un tipo distinto de disco (por ejemplo, Amazon S3 con una CDN en CloudFront). Cuando tengamos esta configuración preparada en nuestro nuevo entorno, veremos cómo las imágenes y los recursos que subamos van a dejar de verse 🫣. ¿Por qué? Porque la función de public_path o asset no estarán usando el S3 para generar la URL. Además, al usar estas funciones asumimos que los ficheros estarán subidos en una subcarpeta storage y este no es el caso para otros discos distintos del public!

Para solucionarlo viene a nuestra ayuda la facade Storage. Esta facade de Laravel nos da una abstracción del sistema de ficheros configurado en la aplicación, por lo que siempre estaremos usando las rutas correctas si lo usamos:

use Storage;

/**
Esta línea devolverá la URL correcta para ficheros subidos en cualquiera de los posibles valores de FILESYSTEM_DISK
*/
Storage::url($filePath);