Backend for Frontend: Tailoring APIs to Client Needs

The One-API-For-Everything Problem

A web application and a mobile application consume data differently. The web app renders a product page with detailed descriptions, high-resolution images, related products, reviews, and availability across multiple stores. The mobile app renders a condensed card with a thumbnail, price, and a buy button. A third-party integration needs raw product data in a structured format with no UI concerns at all.

When all three clients share a single API, the API designer faces an impossible optimization problem. If the API returns the full dataset the web app needs, the mobile app downloads data it discards — wasting bandwidth on constrained networks. If the API returns the minimal dataset the mobile app needs, the web app must make multiple round trips to assemble its page. If the API supports both through query parameters or field selection, the API becomes complex and every client must understand the full schema to request what it needs.

The backend for frontend (BFF) pattern resolves this by placing a thin API layer between each client type and the backend services. Each BFF is purpose-built for its client. The web BFF composes data the way the web app needs it. The mobile BFF composes data the way the mobile app needs it. Each client gets exactly the data it needs in exactly the format it expects, in a single request.

How BFFs Are Structured

A BFF is not a full backend. It is a lightweight translation layer that sits in front of your actual backend services. It does three things:

Aggregation. The BFF calls multiple backend services and combines their responses into a single response shaped for the client. The web BFF might call the product service, the reviews service, and the recommendations service, then merge the results into one payload. The mobile BFF might call only the product service and return a subset of fields.

Transformation. The BFF reshapes data for the client's needs. Field names can match what the frontend expects. Nested structures can be flattened or restructured. Dates can be formatted. Image URLs can be rewritten to point at the appropriate CDN variant (full-size for web, thumbnail for mobile).

Client-specific logic. The BFF can implement logic that is specific to a client platform. Feature flags that only affect the mobile app. A/B test assignments for the web app. Device-specific asset selection. This logic does not belong in the backend services (which should be client-agnostic) and should not be pushed to the client (where it increases bundle size and cannot be updated without a release).

In a Nuxt.js application, the server routes in the server/api/ directory often serve as a natural BFF layer. They compose data from backend services and deliver exactly what the frontend pages need without exposing the client to the internal service topology.

BFF vs. API Gateway

The BFF pattern and the API gateway pattern are often confused because both sit between clients and backend services. The distinction matters.

An API gateway is a shared infrastructure component that handles cross-cutting concerns: authentication, rate limiting, request routing, TLS termination. It routes requests to the correct backend service but does not reshape the response for specific clients. It is client-agnostic.

A BFF is client-specific. It contains logic about what a particular client type needs and how data should be composed and shaped for that client. It may sit behind an API gateway that handles the cross-cutting concerns, or it may handle some of those concerns itself.

In practice, many systems use both: an API gateway for shared infrastructure concerns and BFFs behind the gateway for client-specific data composition. The gateway routes /web/... to the web BFF and /mobile/... to the mobile BFF. Each BFF then calls downstream services through the gateway or directly.

The risk with BFFs is duplication. If the web BFF and the mobile BFF both need to call the orders service and apply the same business rules before returning data, that logic exists in two places. Mitigating this requires shared libraries or a well-designed API layer in the backend services that pushes business logic down to where it belongs, keeping the BFFs focused on composition and transformation.

When BFFs Make Sense

The BFF pattern earns its keep when you have meaningfully different client types with meaningfully different data needs. Two conditions must both be true:

Multiple client platforms. If you only have a web application, a BFF is just an unnecessary layer between your frontend and your backend. A single well-designed API is simpler. The BFF pattern provides value when you have a web app and a mobile app, or a customer-facing app and an admin app, or a public API and an internal dashboard — clients that consume the same underlying data but in fundamentally different shapes.

Data composition requirements. If each client page can be served by a single backend service call with no reshaping, you do not need a BFF. The pattern provides value when client pages require data from multiple services, combined and transformed in client-specific ways.

If you have one client platform or simple data requirements, skip the BFF. If you have multiple platforms making multiple downstream calls and fighting over API response shapes, the BFF pattern eliminates the compromises and gives each client a first-class API experience.

If you are building a multi-platform application and want to design an API architecture that serves each client well, let's talk.