Explain the Facade pattern. How does it tame subsystem complexity, and where does it appear in frontend code?
Recognising when to hide a tangle of low-level calls behind one clean, intention-revealing interface.
Facade provides a single, simplified interface to a complex subsystem — the client calls one clear method and the facade orchestrates the messy details behind it. The signal: callers repeatedly perform the SAME multi-step dance against low-level APIs — build headers, attach a token, call fetch, check status, parse JSON, map errors — and that sequence is duplicated and easy to get wrong. A facade like `api.getUser(id)` collapses all of it into one intention-revealing call, so callers depend on WHAT they want, not HOW it's assembled. Benefits: it decouples client code from subsystem internals (you can swap fetch for axios, add retry/caching, or change auth in ONE place without touching callers), reduces cognitive load, and gives you a natural seam to test/mock. Frontend is full of facades: an API-client module wrapping fetch+auth+error-handling; a storage service hiding localStorage/IndexedDB/quota logic behind `save/load`; jQuery historically was a giant facade over inconsistent DOM/XHR APIs; a custom React hook like `useUser()` is a facade over fetching, caching, and state. Facade differs from Adapter (which converts one interface to another expected shape) and from Decorator (which adds behavior while keeping the same interface): Facade INTRODUCES a new, smaller interface over many pieces. It doesn't hide the subsystem — advanced callers can still reach underneath — it just offers the easy path for the common case. The only caution is letting a facade grow into a god-object; keep each focused on one subsystem.
Wrapping a repeated multi-step subsystem interaction behind one clean method — API clients over fetch, storage/service layers, SDK wrappers, custom hooks.
O(1) structural; cost is that of the delegated calls.