Romaji to Kana Converter: React & Next.js — Chapter 7, Exercise 3
=====================================================================

TASK
A teammate suggests moving the site's public-facing "converter is
temporarily under maintenance" flag into a NEXT_PUBLIC_ environment
variable, so it can be toggled without redeploying the client UI.
Using this chapter's own real, verified findings, explain why that
plan wouldn't actually work the way they expect, and what the real
fix would be.

SOLUTION

The plan runs directly into the exact behavior this chapter verified
with real, executed code: a NEXT_PUBLIC_ variable isn't read live by
the running app at all -- it's replaced with a literal, hardcoded
string inside the client JavaScript bundle at the moment next build
runs. The chapter's own real grep against a built project confirmed
this concretely -- the actual value (BUILD-TIME-LABEL-XYZ) was
physically present in a static chunk file, while the variable's own
name (NEXT_PUBLIC_APP_LABEL) had vanished from the built output
entirely, meaning there was no live lookup left anywhere in the
shipped code to even point a new value at.

So flipping a NEXT_PUBLIC_ maintenance flag after the app is already
deployed wouldn't do anything. The teammate's own goal -- toggling it
without redeploying -- is specifically the one thing NEXT_PUBLIC_
variables can't do, since "redeploying" here would really mean
"rebuilding," and a rebuild is exactly the step they're trying to
avoid. Every currently-running browser tab, and every new visitor,
would keep seeing whatever value was baked in the last time next
build actually ran, no matter what the server's own environment
variables say right now.

The real fix is the opposite architectural choice this chapter's own
second real finding already demonstrates working correctly: put the
flag behind a genuinely dynamic Route Handler instead, the same way
/api/convert already works. A small route -- say, GET /api/status --
reading a plain, non-prefixed MAINTENANCE_MODE variable would behave
exactly like this chapter's own verified /api/env-test example:
because a Route Handler is dynamic by default (the same real finding
from Chapter 1), it re-reads process.env fresh on every request
rather than freezing a value at build time. The client UI would then
fetch that route on load (or poll it periodically) instead of reading
a NEXT_PUBLIC_ constant directly, and the flag could genuinely be
flipped by changing the server's own environment variable and
restarting the process -- no rebuild required -- exactly the
capability the teammate actually wanted.

WHY THIS WORKS AS AN ANSWER
----------------------------
It correctly identifies that the teammate's plan fails for the same
real, verified reason this chapter demonstrated with a grep against
an actual built bundle -- a NEXT_PUBLIC_ value is frozen at build
time, not read live -- and proposes the real fix this chapter already
proved works: a dynamic Route Handler read by the client at runtime,
which genuinely does re-read the environment on every request.