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.<p>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.<p>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.<p>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.<p>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.<p>The end result is still coupling, and <i>numerically</i> it's actually <i>increased</i> 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') <i>removes</i> the kind of coupling that <i>requires</i> 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.<p>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, <i>independently</i> and to their own timescale. This is the decoupling obtained; it simply works at a different abstraction level.<p>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.