Me pregunto la razón por la cual Django no sirve los archivos estadísticos en producción, cuando DEGUB = False .
STATICFILES_DIRS
Especificamos STATICFILES_DIRS para decirle a Django dónde buscar archivos estáticos que están vinculados a una aplicación específica.
RAÍZ_ESTÁTICA
Especificamos STATIC_ROOT para decirle a Django dónde almacenar los archivos una vez que ejecutamos python manage.py collectstatic , por lo que cada archivo estático se almacena en la ruta especificada en STATIC_ROOT .
Supongamos que establecemos STATIC_ROOT = "staticfiles/" .
Esto significa que una vez que ejecutamos el comando collectstatic, todos los archivos que están dentro de las rutas STATICFILES_DIRS se almacenarán en "staticfiles/"
STATIC_URL Finalmente, especificamos STATIC_URL como "prefijo" para decirle a Djando dónde buscar archivos estáticos, por ejemplo, en la etiqueta HTML <link> , la url que vemos se basa en el valor STATIC_URL
Cuando cargamos nuestro proyecto en el servidor, cargamos el proyecto completo, es decir, cada archivo. ¿Por qué Django no puede servir archivos estáticos cuando se ejecuta en el servidor?
Como acabo de decir, cargamos toda la carpeta, por lo que los archivos que cargamos están allí (¡y los archivos estáticos también!).
Solo me pregunto, ¿por qué tenemos que especificar los archivos estáticos basados en el servidor en producción, cuando Django podría hacer todo por nosotros como siempre lo ha hecho en localhost?
Porque es probable que sea ineficiente e inseguro . Cada vez que se realiza una solicitud, la solicitud pasa por todo el middleware y luego la vista producirá una respuesta que volverá a pasar por el middleware al cliente. Si solicita el mismo archivo por segunda vez, es probable que no tenga ningún almacenamiento en caché y, por lo tanto, repita ese proceso nuevamente. Si trabaja con un servidor web como Nginx/Apache, probablemente almacenará en caché el resultado. Si trabaja con un CDN, entonces también contactará con el servidor más cercano y así obtendrá acceso a estos recursos de una manera más eficiente.
Otro problema es la seguridad. Si especifica una ruta a un archivo que no se debe servir, entonces el servidor web debe evitar que el navegador acceda a ese archivo. Algunos hackers, por ejemplo, intentan acceder a los archivos fuente del navegador para luego buscar vulnerabilidades. Esto no debería ser posible. Es probable que un servidor web como Apache o Nginx tenga mecanismos de seguridad más avanzados para esto.
Si realmente lo desea, puede usar WhiteNoise para permitir que Django sirva archivos estáticos y archivos multimedia en producción. Esta aplicación Django ha sido optimizada para seguridad y eficiencia. Aunque es difícil saber si tendrá el mismo nivel que un servidor Apache o Nginx.
¿No es mucho más lento cargar los archivos desde otro almacenamiento que cargarlos desde la carpeta principal del proyecto?
El servidor web no se pondrá en contacto con el otro almacenamiento: el navegador lo hará. Por lo tanto, es posible que en lugar del servidor web, se contacte con un CDN. Es posible que esto sea un poco menos eficiente, ya que un navegador web generalmente reutiliza la conexión abierta al servidor para realizar más solicitudes, pero a menudo ya se comunicó con ese CDN, por ejemplo, para archivos JavaScript. Además, las CDN están optimizadas para entregar contenido de la manera más eficiente posible: el navegador generalmente se comunicará con un navegador cercano al cliente y, por lo general, también hay equilibrio de carga y redundancia para que sea menos probable que el servidor ya no pueda atender el recurso.