Concretely, what does a BFF do differently when serving a mobile app's product page versus a desktop web app's product page, and how does it accomplish that?

## Fan-out, then compose The core mechanism is **fan-out-then-compose**. When a client requests a screen, the BFF issues calls to each domain service that owns a piece of that screen's data - say: - a **catalog service** for the product description, - a **pricing service** for the price and any discounts, - an **inventory service** for stock status, - and a **reviews service** for the rating summary. These calls are independent of each other, so a well-built BFF issues them concurrently (via async/await, coroutines, or reactive streams) rather than one after another; this matters because sequential calls make total latency the sum of every call, while concurrent calls bound latency to roughly the slowest single call. Once results come back, the BFF composes them into one response object shaped specifically for that client's UI - not a generic "product" resource, but literally the fields that screen's rendering code consumes, in the shape it consumes them. ## Why the shape differs by client The shaping differs by client because the constraints differ by client. - **Mobile.** A mobile device on a cellular connection pays real cost - latency, data usage, sometimes literal money on metered plans - for every extra kilobyte and every extra round trip, so the mobile BFF strips unused fields, sends smaller image variants (or CDN URLs pointing at pre-resized images), and may paginate secondary content like reviews rather than including all of it up front. - **Desktop web.** A desktop web client typically has more bandwidth and a bigger viewport, so its BFF can afford to include a fuller object graph - more review text, higher-resolution images, additional metadata used for SEO or a wider layout. This isn't a difference in what data theoretically exists; it's a difference in what's worth shipping over the wire for that device and screen. ## Reshaping, not only trimming Beyond payload trimming, the BFF also does structural reshaping: - **renaming** backend field names to match the client's view-model naming; - **flattening** nested backend responses into the flatter shape a UI component expects; - **merging** data that lives in two backend services into one field the client renders as a single line (e.g., combining a discount percentage from `pricing-service` with a promotional label from a separate `promotions-service` into one "badge" string). This means client code can bind directly to the response without a transformation layer of its own, which reduces client-side complexity and bugs. Some BFFs go further and hold client-specific caching or feature-flag logic, letting one client see an experimental layout while another doesn't, entirely at the BFF layer without touching the domain services. ## The trade-off The trade-off is that this orchestration work has to be done well, or it becomes the weakest link. - If the BFF calls its four dependencies sequentially instead of concurrently, response time becomes additive and any single slow dependency drags down every request. - If one dependency - say the reviews service - goes down or starts timing out, a BFF without per-dependency timeouts and circuit breakers will hang or fail the entire page rather than degrading gracefully. The correct behavior is to bound each downstream call with its own timeout, treat non-essential data (like reviews) as optional, and return the rest of the page - possibly with a cached or stale version of the missing section - rather than failing the whole request over one slow dependency. This requires the BFF and the client to agree on a contract about which fields are guaranteed versus best-effort, which is a design decision, not something that falls out automatically from adding a BFF. ## A concrete illustration A concrete illustration: an e-commerce product page BFF for a mobile app might return a payload with a thumbnail URL, a two-line truncated description, a price, and a stock boolean, deferring the full review list to a separate paginated call triggered only when the user scrolls to that section. The same BFF's desktop counterpart (or a separate web-BFF) might return the full description, a full-resolution hero image, and the first page of reviews inline, because the web layout has room to show them immediately and the network cost of doing so is acceptable. Both BFFs call the same catalog, pricing, and reviews services underneath - the divergence is entirely in what gets requested, how much of it, and how it's packaged for that specific client.