Exercise 1: Reusing Apache vs. Standing Up nginx From Nothing — Possible Solution
====================================================================

WHY THIS COURSE CAN REUSE APACHE DIRECTLY
------------------------------
Per this chapter, the site's live production server is already running Apache to serve the current PHP-based site. Laravel deployment only needs one additional VirtualHost block, pointing DocumentRoot at the Laravel application's public/ directory, plus a FilesMatch directive routing .php requests to a PHP-FPM pool via mod_proxy_fcgi. The TLS certificate, the domain configuration, and the web server process itself are all already running and simply extended, not replaced.

WHY NEXT.JS AND DJANGO HAD TO STAND UP nginx FROM NOTHING
------------------------------
Per this chapter, neither Next.js nor Django is a technology the live Apache server was ever configured to run - Next.js needed a Node process manager (PM2) and its own reverse proxy layer, and Django needed a WSGI server (gunicorn) and its own reverse proxy layer, and in both cases nginx was chosen and configured entirely fresh, since Apache had no existing mechanism suited to proxying requests to either kind of application server.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains that Laravel's deployment only extends the already-running Apache with one VirtualHost and a PHP-FPM proxy directive, and correctly explains that Next.js and Django needed an entirely new reverse-proxy layer because neither technology could be served by Apache's existing configuration.