bran.name

Pattern: Backend for Frontends (BFF)

Published

Disclaimer: None of what is written here is new, and none of these things are my own ideas. These ideas are all from other people. This article is only a summary of what other articles already specify. This article is a useful overview of the current thinking. See sources at the end for the original works.

Why

  1. Multiple clients, multiple user experiences

    A web app and a mobile app have conflicting requirements on a server. One or multiple BFF’s can be used to isolate these requirements into their own services, each servicing their own client. In other words, the BFF pattern is useful when you want to avoid customising a single backend for multiple interfaces.

    • As a result, each BFF can be smaller, less complex and likely faster than a generic backend that tries to satisfy the requirement for all interfaces.

  2. Team autonomy

    When a BFF is used because there’s a client-side/server-side team boundary, it often results in further decoupling the teams (which can be an advantage or a disadvantage!). This team autonomy has 2 effects:

    • The server-side API’s developed by server-side developers then have to cater less to the client-side developers’ needs, which aids reuse and separation of concerns. The ‘backend’ services become purely business logic, separated from the UI code.
    • The BFF service, developed by client-side developers, is 100% catered to the client-side app needs, which increases efficiency and specificity. If the client-side developers want to decide GraphQL is a better choice than what the microservices internally use, they can pivot quickly by themselves.

  3. Web-specific requirements (UI as a separate concern, UI loose coupled)

    Serving a web app can create very specific requirements for the backend, just an API server might not suffice for a good UX. A web server that is capable of all HTTP features and serving HTML in just the right way is probably a completely separate concern, even if it’s just 1 client. When you want to have (the option of) (partial) server-side rendering, the BFF is the obvious place to do this.

    • As a result the business logic and downstream services can be implemented as general purpose API’s.

  4. Multiple services to call

    When working in a microservice context where the ‘backend’ isn’t a single service, it makes sense for a client-side application to not call multiple different services. There’s various reasons for that; less services to expose publicly, less code and less complexity in the browser, better performance without the added network latency and client hardware limitations, less different API protocols to support from a browser context (e.g. a microservice landscape which has SOAP, REST and gRPC).

Why not

What

How

Sources