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.
Try playing with the metaphor a bit more broadly. Is it luxurious for a behaviour to have its own dedicated class, or a c file to have its own header file?
> If you can somehow charge an insane premium for this BFF setup, then have at it. I'd rather grab my own coffee.
In this metaphor, you're the coffee shop owner. If the customer grabs his own coffee, that's fine, but he should probably grab it from home. It is not reasonable to expect the customer to enter the coffee shop, pour his own coffee and operate the cash register.
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.
GraphQL got out just some years after BFF introduction, but even today BFF works nice while having a monolithic after that it brings a lot of hell / problems..
In distributed cases, BFF makes it a lot harder: aggregation or federation of API which are far way more complex subjects. (how to works with teams, who define data constrains, how to ensure data constrains are followed, etc.)
Let’s say you have a front end application that calls the getUserAge service call from 4 different locations. And the application is being actively developed so the number and locations of calls are only gonna increase.
Do you think an application which directly calls the service from the different locations is as equally coupled as an application where all those code locations call a single function which then is the only place where the front end application makes the request to the service? Do you think the effort involved to change to a new service would be the same in both cases? And do you think the effort involved to change the service would change at the same rate in both cases if the number of callers were 10x or 100x than they were before?
Assuming you do agree with me that the 2nd option, with an intermediary function, would require less effort and less change in effort it’s quite clearly less coupled.
That’s an illustration of how inserting an intermediary B (the function in this example) can still lead to lower coupling even if the number of calls between A and C are unchanged.
That example assumes a frontend that makes TONS AND TONS of small http requests to do even the simplest thing. That's obviously stupid and bad yea. But the article doesn't start with that premise as far as I can see.
Instead of one tight coupling between the customer and the coffee machine, you have two tight couplings: one between the customer and the barista, and one between the barista and the coffee machine.
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.