BFF, Backend for Frontends
aien.me
aien.me
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.
> 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.
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.
Every page can use a (named) query for just the objects needed, and just the fields of those objects.
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.)
As in "microservices"? Well.. I think we all know having microservices makes everything harder and almost everything worse :P
It's not to say it's guaranteed. Tight coupling could remain if A and C still communicated via structs defined in A or C.
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.
What you’re describing is more like an API gateway.
A is your React app, C is your Java service, and B is the hypothetical bff that might be inserted between.
Decoupling is not disconnection.
If B is (well-)implemented, your React app and Java service do not know about each other.
So instead of one tight coupling and two components to manage, you now have two tight couplings and three components to manage.
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.