In the Backend for Frontend pattern, a service (“the backend”) serves as a termination point for a requesting interface (“the frontend”). The backend coordinates all subsequent calls within the solution architecture pursuant to any frontend request.
Backends within this context differ from a traditional API or monolithic gateway. Public APIs are monolithic user interface endpoints, terminating all traffic regardless of modality. For instance, a public API will typically service both browser and mobile traffic.
The BFF will do the following.
Call the relevant microservices APIs and obtain the needed data
Format the data based on the frontend representation
Send the formatted data to the frontend
If requirements across mobile, browser and other modality constituents vary significantly and the time to market of a single proxy or API becomes problematic, BFFs are a good solution. One must only ensure that you limit the downsides using the following practices.
The purpose of having a BFF is to provide your client a focused interface to connect with. For example, data consumption by a mobile UI could be different from data consumption by a browser. In that case, for better data representation, two BFFs can be used.
Let’s have a look at an application diagram with multiple BFFs.
BENEFITS OF BFF
The BFF pattern comes with many potential benefits.
May reduce the chattiness of the client with an implementation by serving as an aggregator and coordinator of requests
Smaller and less computationally complex than an all-encompassing monolithic API (segmentation by the AKF Scale Cube Y axis vis-à-vis differing modality of requests)
Faster time to market as front end teams can have dedicated back end teams serving their unique needs, vs. a combined monolithic team servicing the needs of competing constituent front end teams
May offer better results for each front end constituent, vs “in between” solutions that are optimized for neither constituent
DRAWBACKS TO THE BFF PATTERN
There are two very obvious drawbacks of the BFF pattern implementation, dealing with fault isolation and the propagation of blast radius for any failure. A handful of additional drawbacks need to be remunerated if BFFs are employed.
Fan Out: If engineers and architects aren’t careful, there can be a high degree of fan-out between any BFF and associated services it calls. The failure of any of those services can bring down the entire BFF for the interface in question
Fuse: Each service, if it responds to multiple BFFs has the capability of bringing down all BFFs and as a result halt all operations. Each individual service then becomes a fuse anti-pattern
Duplication and Lower Reuse: There is a high probability that each BFF may implement similar capabilities with different teams, easily doubling (or more) the cost of development. The benefits of faster time to market may warrant this downside, but if it is a major concern some lightweight overhead associated with identifying duplicate efforts may help identify opportunities for shared libraries that get developed once
More Services and Components: As we segment backends for each constituent frontend, the number of deployable units increases. This becomes less of a concern if teams have good DevOps practices, great monitoring, lots of automation and good ownership around quality of releases
Do's and Don'ts of BFF Pattern
BFF is used as an interface for request handling, data manipulation and formatting. In order to achieve the highest potential of this pattern, you should know how to use this pattern correctly,.
Don's Do's
1. Do not use one BFF for all the requirements Use Multiple BFF's for each requirement
2. Do not use one BFF for multiple experiences use multiple BFF's per experience optimizing
the BFF best to serve the experience
3. Do not fail the entire request from the Process the request partially of sufficient
frontend if partial data isn't available due to service information is extracted from the microservices
Failure and if can be displayed correctly in the frontend
4. dot not except the BFF to handle all the Keep the BFF as a thin layer that process
responsibility. Do not over-rely on the BFF request to be sent to the microservices, an
interface that bridges microservices and the
client applications, and also a thin layer that can
format and process data if and when necessary
to optimize the data for the frontend.
5. Do not have separate teams to merge Allow the respective frontend team to manage
BFF's their respective BFF's
6.Do not merge BFF's together to avoid Develop reusable libraries or independent
code duplication components where it is possible to share
them across the teams
Resources: Medium, Wikipedia
The Tech Platform