One backend to rule them all? Sounds good in theory—until your mobile app screams for smaller payloads, your web app demands richer data, and your backend team is drowning in conflicting requests. That’s where the Backends for Frontends (BFF) pattern steps in.

The Problem

You start simple. A web frontend and a backend service. Life is good. ↓

Then your business decides to launch a mobile app. Suddenly, the same backend has to serve two very different beasts:

• A desktop browser that wants lots of data on a wide screen.

• A mobile app that needs fast, trimmed-down responses because of limited screen real estate and slower networks.

Both hammer the same backend, pulling it in opposite directions. The result? Frequent updates, bottlenecks, and frustrated teams. One change for the mobile team risks breaking the web experience. Backend developers get stuck playing referee instead of building features.

The Pattern

Instead of forcing all frontends to wrestle the same backend, you insert a custom layer for each client: a Backend for Frontend service ↓

• Web app? It talks to its own Web BFF ↓

• Mobile app? It gets a Mobile BFF ↓

• Add Android separately? Spin up an Android BFF ↓

Each BFF is small, focused, and tailored. The web BFF can deliver richer aggregated data, while the mobile BFF can slim down payloads and optimize performance.

Frontend teams own their BFF, picking their release cycle, and priorities. No more waiting on a central backend team to approve every tweak.

Beyond Web & Mobile

This pattern isn’t just about browsers and phones. Hook in third-party systems like Zoho CRM? Yep, you can give them their own BFF too ↓. Each interface gets exactly what it needs without messing with others.

Adding a Gateway

Want to tighten security, logging, and monitoring? Drop a gateway in front of your BFFs ↓

The gateway handles generic perimeter concerns—authentication, logging, rate limiting—while the BFFs stay laser-focused on client-specific logic.

Considerations (a.k.a. Don’t Overdo It)

Before you spin up a dozen BFFs, keep these trade-offs in mind:

• More services = more overhead. Each BFF needs to be deployed, secured, and maintained.

• Latency. An extra hop means slower responses if you’re not careful.

• Code duplication. You’ll probably repeat some logic. Decide if the tailored experience is worth it.

• Don’t dump everything into the BFF. It’s for client-specific logic, not for logging or auth—those belong upstream in gateways or shared services.

• GraphQL alternative. Sometimes GraphQL makes BFFs redundant by letting clients fetch exactly what they need.

When to Use

• Web only? Stick with your backend unless you need heavy server-side aggregation.

• Multiple clients (web, iOS, Android, third parties)? Use a BFF per client. The separation of concerns and team autonomy are worth the extra services.

• Split teams? If your frontend and backend teams are different groups, BFFs cut down on cross-team bottlenecks.

The Bottom Line

The Backends for Frontends pattern is about freedom and focus. It frees backend teams from endless compromises and gives frontend teams the power to deliver the best possible experience for their users.

Next time someone suggests cramming all frontend needs into one backend, show them the diagrams above. Then tell them: “Let’s give each frontend its own friend.”