Exercise 3: Why None of Chapter 1's Three Claims Were Treated as Unconditional Wins — Possible Solution ==================================================================== ASYNC-NATIVE: BOTH A GENUINE WIN AND A GENUINE NON-WIN ------------------------------ Chapter 3's lookup route and Chapter 9's recipe fan-out both genuinely benefit from async, since both wait on real, slow external network calls where the event loop staying free to serve other requests actually matters. Chapter 6's alerts route, by contrast, was deliberately written as a plain def, since a local SQLite query finishes almost immediately and gains essentially nothing from being async - the course states this honestly rather than pretending every route benefits equally. PYDANTIC VALIDATION: A REAL WIN, NAMED CONCRETELY ------------------------------ Chapter 5's create_item route contains no validation code at all, because ItemCreate's own type declaration already guarantees valid data by the time the function runs - a genuine elimination of an entire category of hand-written checks other courses in the quartet still need. This is one of the claims that held up as a clear, unqualified benefit. AUTOMATIC DOCS: A WIN WITH A REAL CAVEAT ------------------------------ Chapter 1 praised /docs as genuinely automatic and valuable during development, something none of the sibling courses get for free. Chapter 11 revisited that same feature honestly, pointing out that leaving it enabled in production means anyone can make real API calls through that same public page - a genuine benefit that still needed a deliberate, examined decision before shipping, not an automatic default. WHY THIS WORKS AS AN ANSWER ------------------------------ It gives one concrete example for each of the three original claims, correctly showing that async was shown to genuinely help in some places and genuinely not help in others, Pydantic validation held up as an unqualified win, and automatic docs was revisited with an honest production caveat rather than treated as costless.