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

TASK
Given Chapter 5's own real, measured verdict that client-side
conversion is objectively better for this feature, explain in your
own words why this chapter still builds out a full deployment story
for the server-side route rather than simply recommending it be
deleted.

SOLUTION

Chapter 5's own conclusion was specific to what's actually best for a
finished, real-world version of this app: given that convert() has no
secret to protect and no shared state to manage, paying a real,
measured ~10,000x latency cost for a server round trip has no genuine
benefit attached to it, so the client-side box is the right default
for anyone actually using this tool.

But this course isn't only building a finished production app -- it's
also teaching, chapter by chapter, what a real server-side alternative
looks like, including how it gets deployed once it exists. Deleting
/api/convert after Chapter 5 would mean nobody reading this course
could ever load the finished site and try both approaches side by
side for themselves, the way Chapter 5's own comparison depends on
both boxes genuinely working. Keeping the route alive and correctly
deployed is what makes Chapter 5's own real, measured evidence
something a reader can go verify hands-on, rather than a claim they
just have to take on faith from the chapter text.

There's also a real, concrete piece of value the deployed route
leaves behind on its own: a working, correctly-configured example of
Astro's on-demand rendering, the Node adapter, and a real rate-limited
API route, all pattern-matchable directly for any future feature this
project (or another one) genuinely does need to run server-side --
exactly what Chapter 5's own closing tip-box already named as the real
reason the route wasn't wasted effort, even though it loses the
comparison it was built to run.

WHY THIS WORKS AS AN ANSWER
----------------------------
It distinguishes what's best for a finished production app (Chapter
5's own real verdict) from what's actually needed for this course to
teach and demonstrate both approaches honestly -- and names two
concrete reasons to keep the route (letting readers verify the
comparison themselves, and leaving behind a real, reusable deployment
pattern) rather than treating "keep it anyway" as an unexplained
contradiction of Chapter 5's own conclusion.