Microservices Backend for Frontend

A website, an Android app, and a smartwatch all show data from the same services, yet each screen needs a different slice of that data. Forcing every client through one general API leads to bloated replies and awkward workarounds. The Backend for Frontend pattern, shortened to BFF, gives each type of client its own small backend that speaks the client's language.

Layman Explanation

A hotel kitchen serves a breakfast buffet, a room-service tray, and a banquet hall. Each setting needs different portions, plates, and timing. A dedicated server for each setting collects food from the same kitchen and presents it the right way. A BFF acts like that dedicated server for every client type.

The Problem with One Shared API

• Mobile apps download fields they never show, which wastes data and battery.
• Web pages call five endpoints to build one screen.
• Every client team waits for the single API team to approve changes.
• Changes for one client risk breaking another.

Diagram: One BFF per Client

 Web browser  ----> Web BFF    ----+
                                   |
 Mobile app   ----> Mobile BFF ----+----> Catalog service
                                   |      Orders service
 Smart watch  ----> Watch BFF  ----+      Profile service

Each BFF calls the shared services, trims the data, and returns exactly what its client needs.

What a BFF Does

Aggregation

The BFF calls several services at once and merges the results into one reply. The client makes a single request in place of five.

Shaping

The BFF removes unused fields, renames values, and converts formats. The watch BFF might return only an order status and a delivery time.

Client-Specific Rules

The mobile BFF can compress images to a small size. The web BFF can return larger images and extra detail for wide screens.

Example: Home Screen Request

Mobile app asks: GET /home

Mobile BFF calls in parallel:
  Profile service   --> name, avatar
  Orders service    --> latest 2 orders
  Offers service    --> top 3 offers

Mobile BFF replies with one small JSON document:
  { "name": "Ravi", "orders": [...2], "offers": [...3] }

BFF vs API Gateway

Feature	API Gateway	BFF
Audience	All clients	One client type
Main job	Routing, security, limits	Shaping and combining data
Owner	Platform team	The client team

Both fit together. The gateway handles authentication and rate limits at the edge, and the BFFs sit behind it.

Team Ownership

The team that builds the mobile app owns the mobile BFF. That team ships changes on its own schedule and no longer files tickets with a central API team. Speed rises and responsibility stays clear.

Risks to Watch

• Duplicate logic across BFFs. Move shared business rules into the underlying services.
• Too many BFFs. Create one per distinct client experience, not one per screen.
• Fat BFFs that hold business rules. Keep them thin and focused on presentation.

Technology Choices

Many teams write the BFF in the same language as the client team, such as Node.js for a JavaScript front end. GraphQL fits well here because clients ask for the exact fields they need, and the BFF resolves them from several services.

Key Takeaways

A BFF tailors backend responses to one client type. It reduces network calls, shrinks payloads, and frees client teams to move quickly. Keep each BFF thin and let shared services own the business rules.