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

TASK
Suppose kanji conversion (Chapter 6) is eventually built, adding a
new route at /api/convert-kanji that calls a real Redis instance.
Explain what would need to happen for that new route to work
correctly once this chapter's own basePath mounting is in place --
would the real Redis calls inside the route handler itself need any
changes, or only the client-side code that calls the route?

SOLUTION

Only the client-side code that calls the new route would need a
change -- the Redis calls inside the route handler itself would need
none.

The reason traces back to exactly what basePath actually governs.
This chapter's own real testing confirmed that basePath changes
where, on the site's own domain, a browser has to look to find this
Next.js app's own pages and routes -- it moved the app's own root
from / to /romaji, which is why a raw browser-side fetch('/api/
convert') broke and had to be rewritten to fetch('/romaji/api/
convert'). That's a genuinely browser-facing concern: it's about the
address a client uses to reach this specific app, on this specific
domain, from the outside.

A real redis.get() call made from inside a Route Handler is a
completely different kind of network request, made from a completely
different place. It doesn't run in the browser at all -- it runs on
the server, inside the already-running Node process, and it addresses
Redis directly by whatever host and port Redis itself is actually
listening on (the kind of connection string this course's own
Chapter 6 configured with new Redis({ port: 6390, host: '127.0.0.1' })
in its own benchmark, or a real REDIS_URL environment variable in a
production deployment). That address has nothing to do with what path
this Next.js app is mounted under for browsers -- Redis was never
going to be reached via "/romaji/anything" in the first place, since
it isn't part of this app's own basePath-governed URL space at all.

So a genuinely new /api/convert-kanji route would need the exact
same client-side fix this chapter already demonstrated for
/api/convert -- reading NEXT_PUBLIC_BASE_PATH and prefixing the
fetch() call to the new route with it, the same one-line change
applied a second time. But the code inside that new route handler,
including every real call it makes to Redis, would be copied over
completely unchanged. basePath governs how the outside world finds
this app; it has no opinion at all about how this app, once found,
goes on to talk to other real services behind it.

WHY THIS WORKS AS AN ANSWER
----------------------------
It correctly separates two genuinely different kinds of address --
basePath governing the browser-facing path to this app's own routes,
versus a Redis connection string governing a completely separate,
server-to-server network hop -- and concludes that only the former is
affected by this chapter's own mounting change, so only client-side
code calling the new route needs a fix, never the route's own
internal Redis calls.