Challenge 1: Identify Client and Server — Possible Solution ==================================================================== (a) Weather app on your phone showing today's forecast -> CLIENT: the weather app on your phone. -> SERVER: a remote weather data provider somewhere else, holding the actual forecast data. The app doesn't calculate the weather itself — it sends a request ("what's the forecast for this location?") to a server and displays whatever comes back. (b) A browser loading a news website -> CLIENT: the browser. -> SERVER: the news website's web server. The browser asks for a page; the server sends back the HTML, images, and article content that make up that page. (c) A smart thermostat reporting the current temperature to an app -> CLIENT: the thermostat. -> SERVER: whatever backend service the phone app itself later reads from. This one is worth pausing on: the thermostat is initiating the action (sending its reading somewhere), which makes IT the client in this specific exchange — even though your first instinct might be to think of the "app" as always being the client. The role isn't fixed to a type of device; it's fixed to who is asking vs who is holding/receiving the data in a given exchange. The same thermostat could also act as a SERVER in a different exchange — for example, if the phone app asks the thermostat directly for its current setting. WHY THIS WORKS AS AN ANSWER ------------------------------ The client/server distinction isn't about what KIND of device or app something is — it's about direction: whichever side is INITIATING the request is the client, and whichever side is HOLDING the data or doing the work being asked for is the server, for that specific exchange. Example (c) is the trickiest because it flips the pattern you'd expect from (a) and (b), which is exactly why it's included — the same device can be a client in one exchange and a server in another, depending on which way the request is flowing.