Table of Contents
How Simple Engineering Works
What Happens When We Decide to Scale or Mature the Project
What the Heck is BFF?
How BFF...
For further actions, you may consider blocking this person and/or reporting abuse
Didn't know about the concurrent requests limit at browser level. Every day one learns something new. Thanks.
Thanks @aloisseckar , glad i was able to help 🙂
I remember joining as an intern and asking why the heck do we have a backend server like BFF apart from the services that serve data using business logic, wish I had this article back then. This is simply the best article explaining Backend for front end type architecture!
Absolutely! This is awesome stuff. 👌
HTTP is having the limitation to send a max request upto 6 - 8 depends on browsers.
HTTP 1 is having this limitation but HTTP 2 by default allows concurrent requests upto 100 and as it's supporting multiplexing, hence many says unlimited too.
HTTP 2 has the same limitations too.
Except that due to multiplexing you're unlikely to create multiple separate connections and hence hit that limit.
But I'm being pedantic.
You're not wrong.
Pure class 🔥
Thanks @sankha_fb73cb9670f857fb60, learning from you!!!
This definitely works if you have just one frontend app but most orgs that have multiple ones typically use an API Gateway pattern, where it's a separate service, not tied to the frontend code. In those cases BFF usually becomes redundant.
@rcls Interesting perspective! API Gateways are indeed robust solutions for managing multiple frontends by providing a centralized entry point for API requests, handling tasks like routing, authentication, and rate limiting. They work well for general API management across different applications.
However, a BFF can still be very beneficial. By managing specific frontend logic and delivering tailored responses, a BFF customizes data and services for each client type, whether it's a web app, mobile app, or another interface. This helps optimize performance by reducing data transmission and minimizing client-side processing.
For instance, a mobile app might need different data or formats compared to a web application. A BFF can preprocess and transform data to fit these needs, ensuring each frontend gets precisely what it requires. This offloads specific logic and data aggregation tasks from the frontend, simplifying development.
Moreover, a BFF can handle client-specific use cases like caching, error handling, and response shaping, enhancing user experience and application performance. While an API Gateway provides a strong foundation for API management, incorporating a BFF can offer optimized and specific support for each frontend, improving overall system performance and scalability.
Epic read ser!
This image made it pretty intuitive to understand. Thanks!
yes, exactly!
Interesting. But in mentioning moving presentation logic to BFF for different classes of devices I would imagine for responsive design when you resize the screen like of desktop, that has to remain outside BFF. otherwise it's eventing all over to the BFF
Would you consider like AWS api manager a BFF
Great point! @bobbied For responsive design, presentation logic for resizing should stay on the client side to avoid constant communication with the BFF. The BFF should handle data aggregation and transformation, not UI-specific adjustments.
AWS API Gateway can act as a BFF by managing, scaling, and securing APIs, and aggregating data from backend services. However, a dedicated BFF often includes more tailored logic specific to client needs, which might be beyond what an API Gateway alone handles.
Thanks
what about the drawbacks guys ?
Hi @nghia0coder,
Thanks for asking. Here are a few drawbacks I have personally observed when working with BFF:
Increased Complexity: Introducing a BFF adds an additional layer to the architecture, which can increase the overall complexity of the system. Managing and maintaining this layer requires additional effort and resources.
Duplication of Logic: Different BFFs for different clients (web, mobile, etc.) might lead to duplication of business logic. Ensuring consistency across these BFFs can be challenging. You can fix this by creating packages for shared business logic.
Additional Maintenance: Each BFF requires regular updates and maintenance, especially when backend APIs change. This can increase the workload for the development team.
Latency: Although the BFF can reduce the number of requests from the client, it introduces an additional hop in the network. This can potentially increase the latency for some operations, although it will be super minor.
thank you so much
Thanks a lot for asking that question :)
I feel a GraphQL BFF would be super cool. It would dramatically declutter everything.
Thanks! Great explanation of the BFF concept.
Thanks @piotr_majewski_40a87838d5 , glad i was able to help 🙂
I enjoyed this article. Thank you!
Thanks, @cristina_belderrain_b66a2. It was one of my first tech articles, but I'm glad I was able to help 🙂
How does this differ from MVC pattern?