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.
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.
@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
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"
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?
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.
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.
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
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.
Concise, to the point, with great clarity on the pros and cons. Very well explained!
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.
i only know api gateways lol
Great video with the topic well explined. 6 mins and I'm in!.
Best educational videos on headless solution.
Backend for a frontend...I have known a few of those... well explained.
It was a pleasure to watch this. Thank You.
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.
The easiest video for bff beginners!
Very nicely explained! Haven't seen any comparable explanation which was equivalently well presented. Pls keep going
Beautifully explained
Amazing, perfect video for what I need!
Very nicely and concise explained. Thank you!
thank you, very helpful
Great channel! Will be nice to have a video about API Gateway and BBF. When use API Gateway, BBF, both???
Sounds like a good idea ill pit it on the list
Best friend forever💅
@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
great explanation
Thanks for the help
Great content, John! Would you say it's common to see a headless software architecture being used with microservices/containers?
Very well explained! Thank you :)
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"
Thanks a ton :)
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?
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.
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.
brilliant
real-life example will be good
what is the typical or recommended stack, framework or language used for a BFF?
Would the BFF also be built as a bunch of micro services or would you say that is an overkill?
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
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.
Use graphQL
Was thinking the same thing. But would this fully replace all benefits of a BFF, or only partial?
I feel like this practice is self-evident, but teams have implemented microservices poorly, so now we need a new buzzword
Graphql fit there
okok