Romaji to Kana Converter: Angular & Express — Chapter 8, Exercise 3
=====================================================================

TASK
Build with only --base-href /romaji/ set, using just the default
"production" configuration (skip "mounted" entirely, leaving
apiBaseUrl empty). Serve it through the same nginx proxy from
Exercise 2 and confirm the page itself loads correctly while every
conversion attempt fails -- demonstrating why this chapter's own
warn-box treats the two fixes as genuinely separate.

SOLUTION

  $ ng build --base-href /romaji/
  // note: no --configuration flag at all here, so this is a plain
  // "production" build -- environment.ts's own empty apiBaseUrl ships
  // unmodified, exactly as it did at the end of Chapter 7

  $ cd romaji-converter-api && node server.js

With the same nginx proxy from Exercise 2 still running:

  $ curl -s http://localhost:8080/romaji/ | grep -o '<title>[^<]*'
  <title>Romaji to Kana Converter

The page itself loads fine -- --base-href alone was enough to fix
every asset reference, so the HTML, JS, and CSS all resolve
correctly.

Opening the page in a real browser and typing "sushi" into the input,
then checking the DevTools Network tab:

  Request URL: http://localhost:8080/api/convert
  Status: 404 Not Found

The request went to /api/convert at the domain root -- not
/romaji/api/convert -- because apiBaseUrl is still the empty string
from Chapter 7's own default environment.ts. nginx's own config only
proxies requests under the /romaji/ location; a bare /api/convert
request at the root never matches that location block at all, so
nginx just returns its own default 404, and the output panel shows
the real "Couldn't reach the conversion service" error message from
Chapter 6.

WHY THIS WORKS AS AN ANSWER
----------------------------
It confirms exactly the split this chapter's own warn-box predicts:
--base-href alone is genuinely sufficient to make the page load and
render correctly, because it only ever touches how assets are
referenced -- but with apiBaseUrl left at Chapter 7's own empty
default, every API request still resolves against the domain root
instead of the actual mounted path, and fails outright. A correctly
loading page and a working app are two separate outcomes here, and
this test isolates exactly which of the two fixes is responsible for
each one.