Exercise 1: Why Proxy the Lookup Through Express — Possible Solution
====================================================================

THE THREE REASONS
------------------------------
1. Caching — the same barcode gets scanned repeatedly over time by
   this app's own users, and caching the result server-side avoids
   re-querying Open Food Facts for a product it has already looked up
   before.

2. Consistency — every client (this React app today, a future mobile
   app tomorrow) gets identical lookup behavior, because the logic
   lives in exactly one place rather than being duplicated in every
   client that wants to look up a barcode.

3. Future-proofing — if Open Food Facts' own API response shape ever
   changes, or a second product-data source gets added later, only
   the server-side route needs to change; every client keeps working
   without modification.

WHY NO API KEY DOESN'T CHANGE THE ANSWER
------------------------------
Open Food Facts is free and requires no API key, so there's no secret
credential this proxy is protecting. The three reasons above are about
caching, consistency, and maintainability, not secrecy — which is why
proxying through the server is still worth doing even for a fully
public, keyless API.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly names all three reasons from the chapter, and it correctly
explains why the absence of an API key doesn't undermine the case for
proxying — since the actual justification was never about hiding a
secret in the first place.