BFF (Back for frontend) Architecture

A brief introduction

Photo by Avel Chuklanov on Unsplash

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:

1. 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
2. Isolation of the business backend from the specificities of the front ends (security, call optimization, integrations…)
3. 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
4. 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:

1. 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
2. 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)