Exercise 1: Why a Cloud Function Here, Without a Secret — Possible Solution
====================================================================

WHY IT ISN'T STRICTLY REQUIRED
------------------------------
Open Food Facts is free and public and requires no API key, so there's no secret that would be exposed by calling it directly from the browser with fetch(). Chapter 1 justified Cloud Functions specifically as the place a genuine secret lives, safely away from client code - and that justification simply doesn't apply here, since there's nothing secret to protect.

THE THREE REASONS GIVEN ANYWAY
------------------------------
1. Caching: many different users will scan the same common barcodes, and a server-side cache means Open Food Facts only ever gets queried once per barcode, regardless of how many people scan it afterward.
2. Consistent error handling: normalizing the third-party API's own error shapes (not found, malformed barcode, service unavailable) into one consistent response is easier to do in one central place than in every component that might trigger a lookup.
3. Future-proofing: if a paid, key-requiring nutrition API ever replaces or supplements Open Food Facts, the swap happens entirely inside the existing function, with no client-side changes and no risk of a future key ever touching the browser.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains that no secret is involved here, contrasting it directly with Chapter 1's own justification, and correctly names all three reasons (caching, consistent error handling, future-proofing) the chapter actually gives for using a Cloud Function anyway.