BFF (Back for frontend) Architecture
What is the BFF pattern?
It stands for Back for FrontEnd and allows you to create independent back-end services and their interfaces for front-end applications. This pattern is useful when you want to avoid customizing a single back-end for multiple front-ends, typically with different user experiences and tech stacks.
Sam Newman first described this pattern, you can see a reference on his website https://samnewman.io/patterns/architectural/bff/
How to design solutions correctly with this architecture?
The BFF architecture can be designed on a base of apified services, it allows to establish a front backend service layer that only contains a set of services that respond to specific needs.
What should BFF backend services contain?
The main reasons to use this pattern in an architecture design are
- Optimized APIs for the different front ends, including APIs that optimize the customer experience
- The minimum logic for the BFF, with calls to the specific services of each front end (for example a service that only uses the mobile app or the web app)
What does this architecture give us?
The main advantages are:
- Separation of responsibilities by type of Front, allowing the development teams to be separated by “BFFs” and giving them a specific backend that enhances the solution of each channel
- Isolation of the business backend from the specificities of the front ends (security, call optimization, integrations…)
- It allows the combination of architectures (Microservices, serverless, Legacy System isolation, it combines very well with the use of legacy backends and their modernization and erosion starting with the front ends
- Different development speeds per BFF, being able to start with multiple combinations (several new frontends and a legacy backend) allowing separate teams
What points should be reinforced in this architecture ?
And finnaly what must be thinking in:
- Reusing and coordination of services, given that duplicate services will be produced with total security, both in the apis and in the backend services of each of the BFFs
- Select the correct level of granularity of BFF. For this reason is necessary analyze in your architecure design the number of BFF to build (eg it´s neccesary split a BBF from Android and other for IPhone or a unique BFF Backend)