Backend-for-Frontend (BFF)

The Backend-for-Frontend (BFF) pattern gives each client platform, web, mobile, IoT, its own dedicated backend instead of forcing them all through one general-purpose API. Each backend is shaped to the needs of its frontend, so teams can aggregate and transform data the way their client wants and release on their own schedule.

Context and problem

As an application grows to serve several platforms, a single shared backend ends up trying to satisfy all of them at once. Their needs differ, so the backend faces competing demands, frequent changes, and a delivery bottleneck, and separate frontend teams have to coordinate releases around one another.

Solution

The BFF pattern gives each frontend its own backend, fine-tuned to that client. Each team gains autonomy over language, release cadence, and priorities, and the BFF becomes the place to aggregate data from microservices, transform it for the client, and hide details such as keys and tokens.

Trade-offs

The benefit is adaptability and decoupling: each backend fits its platform, payloads shrink, and problems can be handled in the BFF rather than shipped to the client. The cost is duplication and overhead: caching and reliability logic risks being reimplemented in every BFF, the BFFs must be kept consistent, and each one adds an extra hop, its own resources, and its own deployment to operate.

Where HARP fits

HARP does not build your BFFs, but it removes the cross-cutting work each one would otherwise duplicate. As a forward proxy between your backends and the remote APIs they call, it centralizes the non-business concerns in one place:

• Reliability: caching, circuit breaking, and active and fallback remote pools, applied consistently instead of reimplemented per BFF.
• Request and response handling: the rules engine manipulates requests and responses in the proxy, so transformations and fixes for upstream quirks live in one place.
• Observability: a dashboard, an audit log, and Prometheus metrics give a single view of the traffic flowing through every BFF to the underlying microservices.

This keeps each BFF focused on shaping data for its frontend, while the repetitive reliability and observability concerns stay in HARP.

Conclusion

The BFF pattern helps you serve diverse clients well, at the cost of running and maintaining more backends. It is not worth it when your platforms are very similar. When you do adopt it, routing the BFFs' outbound calls through HARP keeps caching, resilience, and observability out of each backend and in one consistent layer.