Notes on back end for front end architecture

Back-end-for-frontend (BFF) Architecture - Notes

First described and popularized by Sam Newman.
https://samnewman.io/patterns/architectural/bff/

TLDR

You can think of a BFF as a an API specifically tailored to a certain user experience. It acts as an aggregation layer
which sits in front of many microservices and is consumed by a specific client with varying needs, such as an iOS app, 
Android app and traditional web app. Each of these different user experiences may have different BFF APIs.

Why?

- Traditional general purpose API's are supposed to fullfill needs of all clients, but this tends to lead to code bloat
and inefficient team structures and deploy complications.

- Another problem with the general-purpose API backend is that they are by definition providing functionality 
to multiple, user-facing applications. This means that the single API backend can become a bottleneck when 
rolling out new delivery, as so many changes are trying to be made to the same deployable artifact.

Introducing The Backend For Frontend

- Conceptually, you should think of the user-facing application as being two components - a client-side application 
living outside your perimeter, and a server-side component (the BFF) inside your perimeter.

- The BFF is tightly coupled to a specific user experience, and will typically be maintained by the same team as the 
user interface, thereby making it easier to define and adapt the API as the UI requires, while also simplifying process 
of lining up release of both the client and server components.

-  Your organisational structure is one of the main drivers for how many BFF's you will require. Whether you have
an iOS BFF + Android BFF, or perhaps a single Mobile BFF -- this will be determined by whether or not you have a 
separate iOS team + Android team vs a single mobile apps team.

- Another guideline for BFF's was 'one experience, one BFF'. So if the iOS and Android experiences are very similar, then 
it is easier to justify having a single BFF. If however they diverge greatly, then having separate BFFs makes more sense.

Useful with Microservices

- For organisations using a large number of services BFF's can be essential, as the need to aggregate multiple downstream 
calls to deliver user functionality increases drastically.

- BFF's can act as aggregators that make multiple calls in parallel to many services and aggregate the information needed
by a specific user experience.

- In this type of architecture it becomes important that the clients and BFFs can handle partial responses and 
degraded service scenarios.

Downsides

- One of the concerns of having a single BFF per user interface is that you can end up with lots of duplication between 
the BFFs themselves. For example they may end up performing the same types of aggregation, have the same or similar 
code for interfacing with downstream services etc. Some people react to this by wanting to merge these back together, 
and so have a general-purpose aggregating Edge API service. This model, however, has proven time and again to lead to highly 
bloated code with multiple concerns squashed together.