Premier League Predictor: FastAPI & PostgreSQL — Chapter 12, Exercise 2
====================================================

TASK
Explain, in your own words, why this course's own fetch-path fix,
Django's FORCE_SCRIPT_NAME, and PHP's absolute-vs-relative redirect fix
are described as three genuinely different mechanisms solving the same
underlying issue — what is that shared underlying issue?

SOLUTION

The shared underlying issue, in all three sibling courses, is the same
one: an application was originally built and tested assuming it lives
at the web root, and every place it generates or hardcodes a path back
to itself was written on that assumption. Once the app is actually
mounted at a sub-path instead of the root, that assumption becomes
false, and anything relying on it silently points at the wrong real
location — even though nothing about the app's own internal logic
changed at all.

Each course hits that same root-cause problem at a genuinely different
layer, because each course generates or hardcodes its own paths in a
different place:

- Personal Catalogue (PHP & MySQL): the app issues real server-side
  HTTP redirects via header('Location: ...') using absolute paths,
  written directly into PHP code. Once mounted at a sub-path, those
  redirects still point at the site root.
- Personal Catalogue (Django & PostgreSQL): Django's own template
  engine generates links via {% url %} tags based on what Django
  itself believes its own root is — a framework-level, server-side
  assumption fixed with one global setting, FORCE_SCRIPT_NAME.
- Premier League Predictor (FastAPI & PostgreSQL): there's no
  server-side redirect and no template engine generating links at
  all — the paths live as literal strings inside static JavaScript
  files, evaluated entirely in the browser via fetch(). The browser
  resolves those absolute paths from the site's own root, the exact
  same root-relative assumption, just enforced by browser URL
  resolution rules instead of a server-side framework.

All three are really the identical bug — "the app doesn't know it's
not at the web root" — surfacing through whichever mechanism that
particular stack actually uses to generate its own internal paths:
PHP's own redirect headers, Django's own template URL generation, and
this course's own static client-side fetch calls.

WHY THIS WORKS AS AN ANSWER
----------------------------
It states the single shared root cause precisely (a root-path
assumption baked in at build time, broken once mounted at a sub-path),
then explains why each of the three courses manifests that identical
cause through a genuinely different mechanism specific to how that
particular stack generates its own paths.