Romaji to Kana Converter: Astro — Chapter 8, Exercise 3
=====================================================================

TASK
Using Chapter 5's own real, measured evidence, explain why the version
of this converter that should actually ship needs none of Chapter 7's
own adapter/PM2/nginx-rate-limiting machinery at all.

SOLUTION

Chapter 5 built a real /api/convert route and ran an actual, measured
benchmark comparing calling convert() directly in the browser against
calling it over a real HTTP round trip: roughly 1.36 microseconds per
call direct, against roughly 14,084 microseconds per call over HTTP --
a real, measured difference on the order of ten thousand times slower
for the server route, re-confirmed at a smaller but still enormous
~7,000x ratio at a larger sample size. Chapter 5's own honest verdict
was that this specific feature has no genuine reason to pay that cost:
convert() holds no secret worth protecting, needs no shared state, and
does no work a browser can't do instantly on its own.

Everything Chapter 7 builds -- the @astrojs/node adapter, the
standalone server process, PM2 process management, and the nginx rate
limit specifically scoped to /api/convert -- exists only to support
that one server-side route staying available and protected in
production. None of that machinery has any purpose independent of the
route it's deployed to serve. If the shipped version of this converter
is the client-side-only box Chapter 5's own measurement recommends,
there is no server-side route left needing a process to run in, a
process manager to keep it alive, or a reverse proxy to rate-limit
requests against -- the entire deployment chapter's own subject matter
becomes unnecessary the moment the feature it exists to support is
dropped from the shipped app.

A client-side-only Astro build is, in fact, fully static output --
confirmed by Chapter 1's own default output: 'static' setting, since
nothing in the client-side version needs export const prerender = false
or any other on-demand rendering. A static build needs nothing more
than the plain file server the rest of the live site already runs on,
which is exactly why the capstone's own recommended integration plan
(a My Tools fragment) never mentions an adapter, a Node process, or
nginx rate limiting anywhere in its own real steps.

WHY THIS WORKS AS AN ANSWER
----------------------------
It grounds the argument directly in Chapter 5's own real measured
numbers (the ~10,000x latency ratio) rather than asserting client-side
is simply "better," and explicitly connects each piece of Chapter 7's
own deployment machinery back to the one route it exists solely to
support, showing why removing that route removes the entire need for
the machinery built around it.