Still don't see the point of this. From your explanation, what I can get is that the bff acts like a mapper between the client and api, you said it helps separating different frontend clients concerns but still I can do that without bff. Sounds like a fancy term, to augment the complexity of applications where the tradeOff for that is pretty small (higher frontend costs, higher latency, because of batching) vs (a mapper / adapter, that by the way could be contained in the frontend itself, if the only reason for its existance is mapping values, and also you get a smaller bundle size maybe.
Exactly, the complexity of mapping and data aggregation still exists, it's just not in the front end anymore. I think the real advantage is separation of concerns; with a BFF, you isolate the complexity of data mapping and aggregation into a single service/component, and remove those concerns from your front end (which might have many other concerns to deal with).
@@jordanwalker7076 I see, I've studied a bit about Amazon API GATEWAY, and there is this thing called mapping templates, which sort of do that, you defined it beautifully, it is about "isolating the complexity of data mapping and aggregation into a single service/component"
@John, thanks for the nice content. Safe to say BFF can be used for query centric purposes [GET requests] and for CUD ops, we fall back to the API Gateway as CUD ops are generally device agnostic? Also in this architecture, how we handle requests where auth tokens need to be validated ? Something API gateway pattern is known for
Don't quite see the benefits described here in terms of reducing complexity, because you haven't really reduced the overall complexity as such, you've just moved it out of the front end. But you still have to do all the mapping and aggregation of multiple calls in the BFF. The real advantage is separation of concerns -- all that complexity (aggregating and mapping data from multiple services) is isolated into its own service.
Its intriguing how the same concepts suddenly change name in the IT world. Many years ago, we had SOA, which brought enterprise service bus, then it came API gateways, and now BFF. My head is spinning with all this terminology referring to the same concepts :)
I have been around long enough to also see the cyclical nature of our industry. Although old concepts are renewed just as in fashion old style revivals always have new and often potent nuances. Seeing similar things before gives you the advantage of deeper insight and understanding of these nuances.
4:30, when you say the front end development teams will be responsible for the BFF's; could this be constrewed that the front end teams are responsible for integration with the BFF's and consulting with a back end team on the design and implmentation of the BFF, or rather that the front end teams are responsible and should take ownership of the entire BFF? Including the design of how the BFF integrates with the relevant back ends? As in my experience the front end teams like integrating with API's as opposed to building and designing them, but perhaps that is just my small sample.
Really great channel and a very important topic when it comes to scalability and independence of each delivery team. I’m currently using this pattern in my current company, currently building a PoC. So far I’ve been having issues when it comes to data consistency and I don’t want to couple the BFF with our micro services communication message buses since we use them as state machines. So I was thinking of exploring persistence on BFF like a materialised view or a redis cache, any pointers in this front?
Is BFF is for initial load of data ? what happens when frontent needs 1 small current data after page load ? should frontend call bff or just call respective microservice ?
The BFF is not for the initial load of data but act as the communication layer between your app and other APIs. It is allows the front end devs to build an API specifically for the app they are building.
The BFF is the API for you frontend team to use so it doesn't have to be microservices, it does seem to me to be overkill, as I the BFF will be sitting on top of your backend that could be built will Microservices
After studying architecture for two weeks, I sketched out this same pattern last night. I didn’t know it had a name. Thanks for making this excellent video.
