· Architecture  · 2 min read

Foundations: What is the BFF (Backend for Frontend) Pattern?

Stop struggling with "One API fits all". Learn how the BFF pattern decouples your frontend needs from your backend complexity.

Stop struggling with "One API fits all". Learn how the BFF pattern decouples your frontend needs from your backend complexity.

In the early days of REST, we dreamt of the “Universal API”—one single backend that would serve our web app, mobile app, and third-party integrators perfectly.

The reality? It was a myth.

Mobile apps need fewer data fields to save bandwidth. Web dashboards need aggregated data from five different services. Trying to satisfy both with a single endpoint leads to bloated payloads and chatty network calls.

Enter the BFF (Backend for Frontend)

The Backend for Frontend pattern proposes a simple shift: instead of a general-purpose API, create a dedicated backend layer for each specific user interface.

The Problem: General Purpose APIs

Imagine a “User Profile” screen.

  • Web Dashboard: Needs user details, last 5 orders, credit score, and recommended products.
  • Mobile App: Just needs the user’s name and avatar.

If you have a single GET /users/{id} endpoint:

  1. Over-fetching: The mobile app downloads megabytes of order history it doesn’t display.
  2. Under-fetching: The web dashboard has to make 4 separate calls (User, Orders, Credit, Products).

The Solution: Dedicated Gateways

With a BFF pattern, you introduce a layer between the UI and your microservices.

graph TD
    Web[Web App] -->|Request| WebBFF[Web BFF]
    Mobile[Mobile App] -->|Request| MobileBFF[Mobile BFF]
    
    WebBFF -->|Aggregates| ServiceA[User Service]
    WebBFF -->|Aggregates| ServiceB[Order Service]
    WebBFF -->|Aggregates| ServiceC[Product Service]
    
    MobileBFF -->|Filters| ServiceA
  • The Web BFF calls all 3 services and returns a single, perfectly formatted JSON object to the browser.
  • The Mobile BFF calls the User Service, strips out 90% of the fields, and returns a tiny, efficient payload.

Key Benefits

  1. Optimized Performance: Payload sizes are exactly what the UI needs, no more, no less.
  2. Simplified Frontend Logic: The frontend doesn’t need to join data or format dates; the BFF handles presentation logic.
  3. Security: The BFF acts as a first line of defense, hiding internal microservice complexity and handling token negotiation (e.g., swapping a Session Cookie for a JWT).

When to Use It?

Use a BFF when:

  • You have multiple interfaces (Web, iOS, Android) with significantly different data requirements.
  • Your backend assumes a microservices architecture that requires aggregation.
  • You want to optimize the “Time to First Meaningful Paint” on your frontend.

The BFF pattern is a cornerstone of modern fintech architecture, where security and performance on mobile devices are non-negotiable.

Back to Blog

Related Posts

View All Posts »