Exercise 2: Why get_alerts Is Synchronous — Possible Solution
====================================================================

WHY CHAPTER 3'S ROUTE BENEFITS FROM async
------------------------------
Chapter 3's lookup route waits on a genuinely slow, external network call to Open Food Facts - a request that could take a meaningful amount of time to complete, during which the process is otherwise idle. Using await client.get(...) with httpx.AsyncClient lets FastAPI's event loop go handle other requests during that wait, rather than that worker being blocked and unable to do anything else.

WHY get_alerts DOESN'T GAIN THE SAME BENEFIT
------------------------------
This route only queries a local SQLite file - an operation that completes extremely quickly compared to a real network round trip. There's very little idle waiting time for the event loop to usefully reclaim by making this route async, since the query itself finishes almost immediately.

WHY IT'S WRITTEN AS A PLAIN def
------------------------------
This chapter uses the classic, synchronous SQLAlchemy Session, not the async-capable AsyncSession and an async database driver - a deliberate, honest scope decision rather than an oversight, since introducing a fully async SQLAlchemy setup would add real complexity without a correspondingly large practical benefit at this app's own realistic scale and query pattern.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains why Chapter 3's route genuinely benefits from being async (a slow external network wait), correctly explains why this route's local, fast query doesn't offer the same benefit, and correctly frames the synchronous choice here as a deliberate scope decision rather than an inconsistency.