Premier League Predictor: FastAPI & PostgreSQL — Chapter 11, Exercise 1
====================================================

TASK
Explain why this course never needed CORS configuration anywhere,
tracing the reason back to a decision made in Chapter 1.

SOLUTION

CORS (Cross-Origin Resource Sharing) exists to solve a specific
problem: a browser blocking JavaScript on one origin (say,
http://localhost:3000, a separate frontend dev server) from making
requests to a different origin (say, http://localhost:8000, a separate
backend API). That restriction only ever comes into play when the
frontend and the API genuinely are served from two different origins.

Chapter 1's own project structure never created that situation. From
the very first working version of main.py, the static frontend was
mounted directly onto the same FastAPI app that serves the API routes
— the same process, the same port, the same origin, for both the pages
a person loads in their browser and the /api/... routes those pages
call. A request from fixtures.js to /api/gameweeks/1/fixtures is a
same-origin request, exactly like a request from one page on a site to
another page on that same site — nothing about it crosses an origin
boundary for the browser to block in the first place.

Because that architectural choice was made in Chapter 1 and never
changed across any later chapter, there was never a genuine
cross-origin situation anywhere in this course for CORS middleware to
solve — it isn't a gap or an oversight, it's a direct, structural
consequence of serving everything from one app since the very first
chapter.

WHY THIS WORKS AS AN ANSWER
----------------------------
It explains precisely what CORS actually protects against (cross-origin
requests specifically), and traces the real reason this course never
triggers that situation directly back to Chapter 1's own StaticFiles
mounting decision, rather than treating the absence of CORS as
incidental.