Backend for Frontend (BFF) is an effective solution for building composable architectures in software development. This pattern addresses the unique requirements of various client platforms, such as web, mobile, and IoT devices, while preserving the benefits of a microservices architecture.

First introduced by Phil Calcado at SoundCloud, the BFF pattern suggests creating a custom backend service tailored for each client platform. These backend services act as intermediaries between frontends and underlying microservices, aggregating and transforming data to meet the specific requirements of each platform. As a result, frontend development is simplified, performance is improved, and maintainability is enhanced.

The BFF pattern is often preferred over alternative solutions when building composable architectures due to several reasons:

  1. Adaptability to Platform Requirements: The BFF pattern allows developers to create backend services that cater to each platform’s unique requirements, data formats, and interaction patterns, leading to better user experiences and more efficient resource usage.
  2. Decoupling of Concerns: By delegating data aggregation and transformation tasks to the backend, the BFF pattern promotes a clear separation of concerns between frontend and backend development.
  3. Flexibility and Maintainability: The BFF pattern enables independent development, deployment, and scaling of backend services for each client platform, fostering faster adaptation to changing requirements without affecting other platforms or services.
  4. Optimized Performance: By providing a dedicated backend for each frontend, the BFF pattern can optimize data aggregation, transformation, and caching, resulting in reduced latency, smaller payload sizes, and better overall performance.
  5. Streamlined API Evolution: The BFF pattern simplifies API evolution management, as developers can introduce new features, make changes, or deprecate outdated functionality without impacting other platforms.

While the BFF pattern offers numerous advantages, it may not be suitable for all situations. In cases where client platforms are highly similar or few in number, alternative solutions like API Gateway or GraphQL might be more appropriate. However, for diverse client platforms requiring tailored experiences, the BFF pattern proves to be a valuable asset in creating adaptable, maintainable, and performant composable architectures.

What is BFF?

Backend for Frontend (BFF) is a pattern that tailors APIs for different clients or user interfaces, such as web, mobile, or other platforms. Instead of having a single API for all clients, BFFs provide customized APIs that cater to the unique needs and requirements of each client, ensuring efficient communication and an optimized user experience.

What is cBFF?

Composable Backend for Frontend (cBFF) is a way of implementing the BFF patterns that leverages a API Repository to compose each BFF API by combining multiple Service APIs, Vendor APIs and data sources into a unified BFF API. This allows for a more flexible and scalable way of implementing BFFs when working towards a composable architecture.

When using BFF on the site, we are referring to cBFF typically.

How can I implement a BFF Architecture?

You can create a BFF architecture by implementing a unique API for each service you want to expose to each client. This can be done by creating a unique API for each client, or by creating a unique API for each service and then composing those APIs into a single API for each client. The latter is the recommended approach, as it allows for a more flexible and scalable way of implementing BFFs when working towards a composable architecture.

One tihng to be aware of is that you do not want to create an API per device (iOS, Android, Web) but rather per device type (Mobile, Web, Public API).

When should I start using a BFF?

You can simply start creating your API using WunderGraph and create multiple WunderNode configurations as your use case requires. This eliminates the need to create customized serivce level APIs or have cross client api duplication.

Alternatively, You would start using a BFF when you have multiple clients that need to consume the same service. This is typically the case when you have a web application and a mobile application that both need to consume the same service. To start, you would create an API for each service, and then compose those APIs into a single API for each client.


Read More