Lesson 5: API Integration and Testing — How We Built a Versioned FastAPI Quiz Platform With Real Test Coverage

Week 5: API Integration and Testing — Building a Quiz Platform You Can Ship and Prove

Most tutorial APIs stop at “it returns JSON.” Production APIs need contracts clients can trust, versions that do not break overnight, and evidence that security and load characteristics were checked—not assumed. This project is a single FastAPI quiz platform that unifies a week of backend engineering: OpenAPI-first documentation, path-based versioning, layered tests from unit through E2E, and a real Gemini-backed question pipeline behind versioned REST endpoints.

You will walk away with a concrete pattern: product routes stay thin, core/ owns behavior, and every curriculum topic shows up as an operational concern (docs tags, middleware, pytest suites, Locust profiles)—not as slide deck vocabulary.

What the system is

The Project is a containerized quiz platform. A static operations console talks to an nginx gateway on port 8080; FastAPI serves learning sandboxes and production workflows under /api/v1 and /api/v2. PostgreSQL persists users and quizzes; Redis backs health and optional caching. Google Gemini generates multiple-choice questions; grading is server-side so the client never sees correct answers until after submission.

OpenAPI enrichment and Swagger live at /docs. Version analytics run in middleware. Unit tests target core/services with an 80% coverage gate; integration tests hit real HTTP routes; Locust, security tests, and E2E smoke run under Docker Compose profiles.

The layout deliberately mirrors how platform teams ship: learning routes are sandboxes, product routes are contracts, and core is the only place business rules accumulate. That separation is what lets you refactor v2 response shapes without re-reading seven lesson folders.

Runtime stack (inferred from the repo)

Core composition: who owns what

The core/ package is the engine. It does not know about HTTP path prefixes; it exposes services, versioning, security checks, and database access. backend/app/ is the API shell: routers, Pydantic models, dependency injection, and lesson-specific demo endpoints that mirror each day’s exercise without polluting product code.

Wiring is explicit in main.py: lifespan initializes the database and seeds a demo user; middleware stacks CORS, request logging, and API versioning; routers mount learning and product trees.

Product handlers delegate in one line of intent: validate body → call repository → map domain errors to HTTP status.