Member-only story
BFF Pattern: When Separate Frontends Need Different API Shapes
Imagine you’re building an application with a web dashboard, an Android app, and an internal operations portal.
The web dashboard needs a detailed order page with customer information, payment history, shipment status, and analytics. The mobile app needs only the order status, delivery estimate, and a few actions. The operations portal needs additional audit information and administrative controls.
All three interfaces use the same backend services.
At first, one shared API seems like the obvious solution. As requirements grow, however, the API begins accumulating client-specific endpoints, conditional response fields, special pagination rules, and compatibility workarounds. A change designed for mobile starts affecting the web dashboard. Frontend teams wait for the same backend team to prioritize their requests.
The problem is not necessarily that the domain APIs are badly designed. The problem is that different user experiences are being forced to share the same presentation contract.
The Backend for Frontend pattern, commonly called BFF, addresses this problem by introducing a backend layer tailored to a particular frontend experience.
