Those first two diagrams about the barista with customers explain it all.

From a customer perspective it is super luxurious to have your own barista. They know my tastes, I never have to wait... But then comes the bill, "€2500 for a cup of coffee?!?". Expecting that you can keep selling €3 cups of coffee in this way is delusional.

Obviously choosing this architecture means you can create 'smooth' conversations from the Front-end's perspective, but it requires an insanely complex system of things underneath it. Expecting that you can efficiently build software like this is also delusional.

Of course there could be valid reasons to do this. As the diagrams indicate, it is about the experience you are providing for people developing applications. I mean a butler level of experience: If you can somehow charge an insane premium for this BFF setup, then have at it. I'd rather grab my own coffee.

Claiming that you are "Simplifying Complex Systems with Backend for Frontends (BFF)" is insane.

Without commenting on the relative merits of monoliths, microservices, graphql, BFFs etc., as an analogy it's possibly worth thinking of the BFFs as interfaces tailored to specific use cases.

For example the backend may provide a reporting facility. For reasons of screen factor the available options and the resulting response data may vary depending upon if you're on a mobile phone or a laptop.

The backend needs to allow for the most complex use case, so its endpoints will likely support all the options and return all the data regardless of the client. It may include filters to mitigate somewhat, but that is also extra complexity.

With the BFF scenario the small form factor device would have its own backend as would the large form factor. The large form factor one would likely transparently proxy the request/response to/from the original backend whereas the small form factor one would be free to offer a more limited (and hence less complex) request/response definition based on the up-front awareness of what the device will be doing.

With this situation the shared functionality, data access, business logic, etc., all exist in the main backend so you still only have the one main codebase to maintain. The teams working on the various form factors only need to manage a thin abstraction layer suitable for their consumers who, in turn, benefit from a simpler API as it is focused to their use case.

The end result is still coupling, and numerically it's actually increased coupling as instead of backend-to-client it is now backend-to-each-BFF plus each-BFF-to-client. However the extra layer in the middle (the 'interface') removes the kind of coupling that requires changes in the main backend to be done alongside changes in the clients. I'm aware that API versioning exists as another possibility, but again the idea here is to present an API directly suited to the consumer - and you can still use versioning within that context.

Each team responsible for a particular BFF is free to roll out their own version of changes, including either hiding/ignoring them if they are not needed, or simplifying them or merging in relevant context if they are, independently and to their own timescale. This is the decoupling obtained; it simply works at a different abstraction level.

Again, I'm not offering a view on which approaches are superior (personally I don't believe a single approach will ever be the best everywhere). I'm pointing out one main benefit which makes BFF worth considerating in case it suits your needs.

Seems like you’d get a lot of the same benefits with GraphQL on a scalable backend like AWS Lambda.

Every page can use a (named) query for just the objects needed, and just the fields of those objects.

Complains about tight coupling, then goes on to create a dedicated backend to cater the needs for each frontend…