Personal Catalogue: Django & PostgreSQL — Chapter 8, Exercise 3
====================================================

TASK
Explain, in your own words, why STATICFILES_DIRS being sufficient in
development doesn't mean it's sufficient in production, and what
collectstatic and STATIC_ROOT actually do differently.

SOLUTION

WHY STATICFILES_DIRS WORKS IN DEVELOPMENT

While DEBUG = True and the project is running via python manage.py
runserver, Django's own development server automatically finds and
serves static files by searching every directory listed in
STATICFILES_DIRS (plus each installed app's own static/ subfolder,
including the admin's own CSS/JS). This is genuinely convenient - no
extra command needs to be run for CSS changes to show up immediately.

WHY THIS SAME MECHANISM ISN'T USED IN PRODUCTION

Django's own documentation explicitly states that its development
server is not designed to serve static files efficiently or securely
at real production scale and traffic - searching multiple directories
per request, and running through Django's own request-handling stack
for what should be a simple, fast file response, is real, unnecessary
overhead a production web server (or a dedicated tool like WhiteNoise)
handles far better. Beyond performance, DEBUG is also expected to be
False in a real production deployment, and the development server's
own automatic static-file-finding behavior specifically depends on
DEBUG being True.

WHAT collectstatic AND STATIC_ROOT ACTUALLY DO INSTEAD

STATIC_ROOT is a separate settings value naming one single real
directory - not a list of source directories like STATICFILES_DIRS, but
one destination directory. Running python manage.py collectstatic
walks every app's own static files (matching what STATICFILES_DIRS and
each app's static/ folder would have found in development) and copies
them all into that one STATIC_ROOT directory. A real production web
server, or a tool like WhiteNoise, is then configured to serve files
directly out of that single, already-assembled directory - a genuinely
faster, simpler lookup than searching multiple source locations on
every single request.

ANSWER: STATICFILES_DIRS works in development because Django's own
development server automatically searches those directories on each
request while DEBUG is True - a convenient but explicitly
production-unsuitable approach per Django's own documentation.
collectstatic instead copies every static file from every app into one
single real directory named by STATIC_ROOT, which a proper production
web server or tool like WhiteNoise then serves directly and efficiently
from - a one-time collection step followed by fast, direct serving,
rather than searching multiple source directories on every request.

WHY THIS WORKS AS AN ANSWER
----------------------------
It explains the real mechanism each approach uses (per-request
directory search vs. a one-time copy into a single serving directory)
and grounds the "not suitable for production" claim in Django's own
documented guidance rather than treating it as an arbitrary rule.