Challenge 2: Splitting a Dynamic Page's Work Between the Web Server and Something Else — Solution Walkthrough

The web server's own job:

Accepting the incoming HTTP request, and — once the final page content
is ready — sending that content back to the browser as the HTTP
response. The web server is the layer the browser actually talks to
over the network; it owns the connection from start to finish.

What has to be handed off:

Reading the user's account balance out of a database and assembling
it into the page is application logic, not something a web server
does itself. The web server can't query a database or run
per-request business logic on its own — it needs a separate
application process (a PHP script, a Python/Django view, a Node.js
handler, whatever the site is actually built with) to do that work,
then hand the finished result back to the web server to relay to the
browser.

Why the split works this way:

Per this chapter's own static-vs-dynamic distinction, a web server's
native capability is reading a fixed file from disk and sending it
back — it has no built-in understanding of "look up this specific
user's balance in a database." That capability belongs to whichever
application framework the site actually runs on. The web server's
role in this exact scenario is strictly the front door and the
messenger: receive the request, pass it to the application, relay
whatever comes back.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise applies the chapter's own "what the web server does
itself vs. what it hands off" distinction to a concrete, realistic
example rather than treating it as an abstract rule — correctly
identifying "database lookup and business logic is not the web
server's job" is exactly the discipline the chapter sets up for later
chapters on reverse proxying.