[makeitdouble]

The article puts forward a slightly different proposition, but IMO BFF in smaller organizations are often managed by backend teams (makes sense seeing that "backend" is still the name...). Same goes for teams with full stack devs, they'll be touching whatever layer they want.

Having multiple layers of backend services can have benefits, and one of these layers would just happen to be dedicated to the public facing frontend. To me the one of the main advantage is to make it easier to manage the security settings and applying different assumptions across the whole API. It is single purpose, so it helps a lot for customization and management (or even choosing a different stack altogether, having different scaling strategies etc.)

It becomes something managed really differently when the "real" backend is opaque and off limits (as describe in the article), but then I'm not sure we should call that "BFF", it's just a regular backend for that team as they have no other backend in charge (i.e if I had a single backend API for a mobile app, that I use to interface with Stripe, I wouldn't call it "BFF", that would make no sense)