tbf i'm not convinced in BFF. It can get messy and over-bloated fast. That's just my experience from my current employer. I'm aware that's an issue of the team which is developing multiple BFFs. We can also consider an API Gateway like KrakenD, Kong, Tyk to modify responses. (it would be possible with nginx too) So we could write less code, probably even less dependencies to maintain. (no additional backends) Graphql is made for this problem too. (REST is easier to implement and has a superior error handling. You need to be check permissions for Grahql carefully. One request can include multiple queries) This isn't a complete list. Just some ideas. Good Video
@sinema7101 I agree that BFFs do introduce more complexity in terms of components and source code to handle. Team structure and skills within teams is also a big factor otherwise a single team handling multiple components can become overwhelming. As for code being bloated, it depends on what bloated means. In my view bloated code is code which handles or tries to do more than it should, like a single API endpoint having to be aware of the specific needs of different clients. In such cases having BFF lets you isolate the needs of each client but then the trade off is more complexity and if you lack the team structure to support it, it just complicates things. Thank you for your feedback.
That’s another way to think about it. Though the meaning that tends to be associated with “gateway” is “one and only” while with BFFs you would expect one per client/platform as you rightly put it.
This will result in lots and lots of duplicate codes. You could just have the microservices hit the same API but different routes. This way it acts as a facade. Then when the requests are received, you make sense of it, reuse the general codes (no duplicates), and then decide to return something unique or general. If you have like 1000 endpoints, you might end up only needing to do this in just a few endpoints.
@pereerecodes the BFF won't be the best for every scenario. For example, I have a project I am leading where we have a mobile client and an admin web client. Their needs (the clients) are starting to differ but we are not going the BFF way. We are doing something similar to what you described. One of the main reasons we decided to do this is because of the team structure, it's a small team. Spawning additional components to manage would be overwhelming for the small team. That said, I think the 2 main driving forces for using the BFF pattern are 1) the different consumption needs of the clients and 2) having the team structure to support it. Yes you would have "duplicate" code in the BFFs, though I prefer to call it similar code, but avoiding duplicate code is not the reason you'll use the BFF pattern. Like with all architectural decisions, "it depends". If avoiding duplicate code is key and you only have a handful of endpoints that can conveniently handle requests regardless of client type then it would be good to go as you have described. Also saves you from maintaining extra components.
Great explanation
Thanks.
tbf i'm not convinced in BFF. It can get messy and over-bloated fast. That's just my experience from my current employer. I'm aware that's an issue of the team which is developing multiple BFFs.
We can also consider an API Gateway like KrakenD, Kong, Tyk to modify responses. (it would be possible with nginx too) So we could write less code, probably even less dependencies to maintain. (no additional backends)
Graphql is made for this problem too. (REST is easier to implement and has a superior error handling. You need to be check permissions for Grahql carefully. One request can include multiple queries)
This isn't a complete list. Just some ideas.
Good Video
@sinema7101 I agree that BFFs do introduce more complexity in terms of components and source code to handle. Team structure and skills within teams is also a big factor otherwise a single team handling multiple components can become overwhelming.
As for code being bloated, it depends on what bloated means. In my view bloated code is code which handles or tries to do more than it should, like a single API endpoint having to be aware of the specific needs of different clients. In such cases having BFF lets you isolate the needs of each client but then the trade off is more complexity and if you lack the team structure to support it, it just complicates things.
Thank you for your feedback.
Good video.
Would you recommend using mono-repo or multi-repo to make it smoother for maintenance and collaborating on a BFF Architectural Pattern?
I would say multi-repo. Each BFF in its own repo. That’s what I’ve done with teams I’ve worked with. Thanks for your feedback.
@@bulama thank you.
Using monolith for peace
😄 yes, monolith works well for a number of situations.
@@bulama It works well for most of solutions
so it's not one gateway but two gateways with dedicated DTO's for each platform
That’s another way to think about it. Though the meaning that tends to be associated with “gateway” is “one and only” while with BFFs you would expect one per client/platform as you rightly put it.
This will result in lots and lots of duplicate codes. You could just have the microservices hit the same API but different routes. This way it acts as a facade. Then when the requests are received, you make sense of it, reuse the general codes (no duplicates), and then decide to return something unique or general. If you have like 1000 endpoints, you might end up only needing to do this in just a few endpoints.
@pereerecodes the BFF won't be the best for every scenario. For example, I have a project I am leading where we have a mobile client and an admin web client. Their needs (the clients) are starting to differ but we are not going the BFF way. We are doing something similar to what you described. One of the main reasons we decided to do this is because of the team structure, it's a small team. Spawning additional components to manage would be overwhelming for the small team.
That said, I think the 2 main driving forces for using the BFF pattern are 1) the different consumption needs of the clients and 2) having the team structure to support it.
Yes you would have "duplicate" code in the BFFs, though I prefer to call it similar code, but avoiding duplicate code is not the reason you'll use the BFF pattern.
Like with all architectural decisions, "it depends". If avoiding duplicate code is key and you only have a handful of endpoints that can conveniently handle requests regardless of client type then it would be good to go as you have described. Also saves you from maintaining extra components.