Mission: the FastAPI model server
Everything this chapter built converges here, and assembly order is the point: get a minimal server answering first, prove it on one realistic exchange, then harden it stage by stage.
The job: assemble the chapter into one serving artifact — in this editor as the stdlib miniature (the starter), and on your machine as a real FastAPI app with the same bones.
The stages:
- Registry-backed startup — the model comes from
load_production(), never a hardcoded path; startup fails loudly if nothing is in production. - Validated predict + health — 422 on malformed input, model
version in every response,
/healthreporting what's loaded. - Structured request log — one entry per prediction (inputs, score, version): the raw material for chapter 47's monitoring.
- Stress case — promote a v5 into the registry (chapter 45's
promote) and show the running server still serves v4 until restart/reload — then implement a reload and note the tradeoff you chose (restart simplicity vs live-reload complexity). - One improvement — a request counter by outcome for the health payload, a canary flag that routes a % of predicts to a second cutoff, or a latency measurement per request: pick one, note why.
On your machine, the same mission in real parts: FastAPI + pydantic models, uvicorn, a Dockerfile (lesson 03), and the gate script (lesson 04) run by CI before the image ships. Feed the whole thing a registry and it hands back a versioned, validated, observable prediction service.