Distributed Application Architecture Patterns

5.4 Backend for Frontend (BFF)

Reduce backend complexity by specialising for each frontend

This pattern is based on Back-end for Front-end (BFF) created by [71], and later by Newman [3, p. 480, 72], Richardson [20, p. 265, 51] and Microsoft [73].

5.4.1 Context

There are several types of clients with the system, and they require server-side aggregation. While the clients are typically individual frontends, this pattern can apply in other scenarios, such as providing an API to a third party [3, p. 487].

5.4.2 Solution

Implement a separate backend for each client. These backends process data from shared services and handle all the necessary aggregation for the client. This provides a natural separation of concerns, helping mitigate the core issue of Offload to Gateway.

Backend for Frontend (BFF)

5.4.3 Potential issues

BFFs can introduce duplicated code. There are several potential ways to deal with this problem.

  1. Extract the code into a shared library, thereby introducing coupling between the BFFs

  2. Merge the BFFs into a single service, thereby devolving back into Offload to Gateway

  3. Use the knowledge of where the duplication arises to introduce new shared services

  4. Tolerate the duplication as it may be worth the trade-off for the better separation of concerns this pattern provides [3, p. 484]

Of course, as always, when introducing any new service, there is the risk of introducing increased complexity and development overhead to the system.

5.4.4 Example

ExampleEshop provides a web interface and two mobile applications for different platforms. Each backend is a separate BFF conforming to the different needs and functionality of the frontends. The mobile app backends might provide a coarser-grained API to reduce the number of requests, leverage that phone screens are smaller and can’t display as much information as a desktop browser, or be structured differently due to the differing designs and user experiences. [72]