BFF

A layer that adapts the backend to the needs of the frontend, aggregating and transforming data to improve the client experience.

What is a BFF?

BFF stands for Backend for Frontend. It is an intermediate layer designed to serve a specific channel or interface, such as a web SPA, a mobile app, or an admin portal.

Its job is not to replace the microservices, but to translate their complexity into responses that are more useful for the UI.

What problem does it solve?

Imagine a frontend that needs:

• user data
• order data
• recommended product data
• additional metrics or state

Without a BFF, the client might be forced to:

• call several services
• understand different formats
• combine responses
• handle distributed errors
• couple itself to internal details

The BFF reduces that complexity.

Core responsibilities

Data aggregation

Combine information from several services into a single response.

Transformation into UI DTOs

Deliver data in a format that is useful for specific screens.

Payload optimization

Reduce unnecessary calls and simplify responses.

Read caching

Store frequent responses to improve latency and reduce load.

Simple orchestration

Coordinate calls between services when the frontend needs a composite view.

What it should not do

It should not contain the core business logic

It can coordinate and transform, but it should not become the layer where the domain lives.

It should not replace the microservices

The services remain responsible for the business rules.

It should not grow uncontrolled

A poorly governed BFF can end up becoming a “monolithic backend for the UI”.

When it provides the most value

The BFF is especially useful when:

• the frontend needs data from several services
• there is channel-specific optimization
• you want to avoid multiple requests from the client
• you need DTOs designed for the UI
• you have several channels with different needs

Single BFF vs multiple BFFs

In some systems a single BFF is enough. In others, it may make sense to separate:

• web BFF
• mobile BFF
• admin BFF

The decision depends on how different the needs of each channel are.

REST or GraphQL

A BFF can be implemented with:

• REST
• GraphQL
• a combination of both

GraphQL is often attractive when there is complex aggregation and a need to control exactly which fields the UI consumes. REST can be sufficient and simpler in many contexts.

Practical example

Let’s take the home screen of an e-commerce site.

The UI needs:

• the user’s profile
• recent orders
• recommended products

The BFF can:

1. Query ms-users
2. Query ms-orders
3. Query ms-products
4. Combine the results
5. Return a DTO ready to render

This way the frontend makes a single call and receives a response tailored to its needs.

Summary

The BFF exists to adapt the backend to the frontend. Its value lies in simplifying the UI, aggregating responses, and reducing coupling, not in absorbing the core domain logic.