Exercise 1: Why This View Takes Roughly N Times as Long — Possible Solution
====================================================================

WHY THE COST SCALES WITH N
------------------------------
The for loop in suggest_recipes issues one requests.get() call per ingredient, one after another, in sequence - each call fully completes (including waiting for TheMealDB's response) before the next one even begins. Since the entire view blocks until every single request has finished, the total wait time is roughly the sum of all N individual request times, rather than being limited by just the single slowest one.

WHAT THE FASTAPI AND FIREBASE SIBLINGS DO DIFFERENTLY
------------------------------
Food Tracker (FastAPI) uses async patterns to issue its outbound requests concurrently rather than one at a time, and Food Tracker (React + Firebase) explicitly uses Promise.all() to fire every ingredient's request at once and wait for all of them together. In both cases, the total wait time is roughly determined by the single slowest request, not the sum of every request's own duration - a genuinely faster outcome for the same underlying task when there's more than one ingredient to look up.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains that the sequential loop's total time scales with the sum of every individual request, and correctly identifies that the FastAPI and Firebase siblings avoid this by firing all their requests concurrently, so their total time is bounded by the slowest single request instead.