Exercise 3: Why Next.js Couldn't Reuse Apache — Possible Solution
====================================================================

WHY LARAVEL, RAILS, AND ASTRO COULD REUSE APACHE
------------------------------
Per this chapter's own comparison table, Laravel proxies to a
separately-running PHP-FPM process via Apache's mod_proxy_fcgi, Rails
embeds Ruby process spawning directly into Apache via mod_passenger,
and Astro proxies to a standalone Node server via mod_proxy_http. All
three frameworks were deployed onto a server whose Apache installation
already had - or could gain via a single module - a real, supported
path for that specific runtime (PHP-FPM, an embedded Ruby interpreter,
or a plain reverse-proxy target).

WHY NEXT.JS COULDN'T
------------------------------
The site's own existing Apache setup was configured specifically around
serving PHP - it has no existing module or configuration path for
proxying to an arbitrary Node process the way mod_proxy_http eventually
gives Astro. Bolting an unfamiliar reverse-proxy capability onto a
production Apache instance that was never previously used that way is a
real, avoidable risk this chapter chooses not to take - especially when
nginx is a genuinely standard, well-documented tool for exactly this
job.

THE PARALLEL TO DJANGO
------------------------------
This chapter explicitly names the same situation Django Rebuild 11
faced - Django also needed a Python runtime (via gunicorn) with no
existing Apache path, and also chose to stand up nginx fresh rather
than force an unfamiliar module onto the live Apache. Next.js and
Django share this specific deployment shape because both need a
runtime (Node, Python) genuinely foreign to what the existing Apache
was ever configured to support - not because of any deeper technical
similarity between the two frameworks.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly identifies WHY the three "modernize in place" siblings
could succeed (Apache already had, or could cleanly gain, a real path
for their specific runtime) and correctly explains that Next.js and
Django share the opposite situation for the same underlying reason -
not coincidence, and not a claim that Node and Python are similar to
each other.