I’m having trouble understanding why Backend for Frontend gets so much attention as a design pattern. To me it looks like just another way to create an abstraction layer between your API and UI, which developers have been doing forever. I get that you need to separate concerns and make your frontend independent from backend changes. But how is BFF actually different from using SDK wrappers or other isolation techniques? Maybe I’m missing something obvious here, but it feels like we’re calling standard practices a new pattern. Can someone explain what makes BFF unique compared to traditional approaches for decoupling frontend and backend systems?
i think you hit a good point. bff does stand out since it’s not just abt decoupling. it’s tailored to each client’s needs, pulling only the relevant data. with most APIs, you often end up with too much or not what you need. so that focus on optimizing is key.
but who’s really responsible for the bff layers? i’ve noticed it can be the frontend teams or backend ones, which sometimes leads to odd dependencies. does that shift the perception of its innovativeness, or is it more about how organizations are set up?
The main difference is where they sit and what they do. Regular abstraction layers go between your app and external dependencies for stability. BFF sits between multiple backend services and specific frontend apps - it’s more like an aggregation layer that transforms data. SDKs and wrappers hide complexity but still make frontends deal with generic data structures. BFF creates custom contracts that match exactly what each frontend needs. No more over-fetching or making tons of API calls just to build one view. I’ve used both approaches, and BFF cuts frontend complexity way down because it handles all the backend orchestration and data transformation on the server instead of dumping that work on the client.