<aside> 🥱

TL;DR

• A single shared API works fine — until multiple frontends have genuinely different, conflicting needs.
• The pain shows up as over/under-fetching, team bottlenecks, and versioning conflicts.
• A BFF is a thin, client-specific layer that shapes downstream data for exactly one frontend.
• It trades one large coordination problem for several smaller, clearer ownership boundaries.
• It adds real operational cost (more services, possible logic duplication) — don't reach for it before you have the pain that justifies it. </aside>

The Villain Nobody Saw Coming

It's 2 PM. Your mobile team's Slack message pops up: "Hey, can the /users/profile endpoint stop sending us the entire order history? We're timing out on 3G."

Ten minutes later, your web team chimes in on the same thread: "Wait, we actually need MORE data on that endpoint — we're rendering a dashboard widget that needs the last 5 orders inline."

You stare at the screen. Same endpoint. Same backend. Two completely different needs. And somewhere, your third client — the partner API integration — is quietly filing a ticket asking why the response format changed again.

Welcome to the world before BFF. A world where one backend tries to be everything to everyone, and slowly buckles under the weight of it.

This is the story of how that backend broke — and how a simple idea, the Backend For Frontend (BFF), brought peace back to the kingdom.

Chapter 1 - The World As It Is

In most systems, this is how it starts — and honestly, how it should start. You build one backend API. It talks to your database, stitches together a few internal services, and exposes clean REST or GraphQL endpoints. Every client — web, mobile, whoever — hits the same API.

It's simple. It's DRY. There's one source of truth for business logic, one team owns it, one thing to deploy and monitor. For a while, this feels like the right call, because it is the right call — at that stage.

Meet the Clients

But "clients" is doing a lot of hiding in that sentence. Let's actually meet them:

• The web app — runs on a fast connection, has a big screen, can afford to render a rich dashboard with a dozen widgets in one page load.
• The mobile app — runs on shaky 3G in a train tunnel, has a small screen, and every extra KB in the payload is a battery drain and a spinner your user is staring at.
• The smart TV app — barely any local processing power, needs pre-formatted, minimal data it can just paint to the screen.
• The partner API — an external team consuming your data contractually, who did not sign up for your internal refactors breaking their integration on a Tuesday.

These aren't just "different UIs." They have fundamentally different constraints: payload size, latency tolerance, auth models, even how errors should be shaped for their users.