A tiny app is the honest place to learn a pattern.
Fetching a temperature is trivial. Fetching it properly — without leaking an API key into the browser, with a clean split between the React client and the Django server — is the reusable skill, and a one-number app is the cheapest place to practise it without any other complexity in the way.
So TempTracker is small on purpose: a focused exercise in the frontend-calls-backend-calls-third-party pattern that every real integration repeats.
If the browser can see your API key, it isn't a secret.
The rules that made it worth building.
The key never reaches the client.
The OpenWeatherMap key lives server-side via
python-decoupleand an.envfile; the React app only ever talks to Django.A clean API boundary.
Django exposes one endpoint,
/api/temperature/, returning plain JSON — the frontend never needs to know OpenWeatherMap exists.Handle the unhappy path.
CORS configured correctly and error handling for a bad key or a failed upstream call, so the app degrades gracefully instead of hanging.
React asks Django, Django asks the world.
The flow is a clean relay: the React app requests the Django endpoint on load, Django calls OpenWeatherMap with the secret key, and the temperature and city come back as JSON the client renders.
/api/temperature/ — no third-party knowledge.Routing the call through Django rather than fetching OpenWeatherMap straight from React is the whole lesson: it's the one place the API key can live without being shipped to every visitor's browser.
CORS is the tax on a split stack.
The predictable first wall was CORS. React on one origin and Django on
another means the browser blocks the request until the server explicitly
allows it — the classic "it works in the terminal but fails in the browser"
moment. Installing and configuring django-cors-headers was
the fix, and understanding why it was needed was the actual value.
The second was configuration hygiene: an app that silently fails when the key is missing is worse than one that says so, which is why the error path got as much attention as the happy one.
Readable at a glance.
The interface is a single responsive card — temperature, city, and nothing competing for attention — styled with Tailwind. For an app whose entire job is to surface one number, the design brief was simply to make that number unmissable and the whole thing pleasant to look at.
Three things, next time.
Let the user pick the city.
A search input would turn a fixed-city demo into something genuinely useful, at the cost of validating input.
Show more than a number.
Humidity, wind, and a conditions description are already in the API response — surfacing them is nearly free.
Cache and rate-limit sensibly.
Caching recent lookups would cut redundant OpenWeatherMap calls and keep the app inside free-tier limits.