Before we begin Let’s clear some basic understanding about Microservices,
What is microservices?
The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.
These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.
Principles of microservice architecture:
- Scalability
- Availability
- Resiliency
- Independent, autonomous
- Decentralized governance
- Failure isolation
- Auto-Provisioning
- Continuous delivery through DevOps
Backend For Frontend (BFF) ?
The BFF is tightly coupled to a specific user experience, and will typically be maintained by the same team as the user interface, thereby making it easier to define and adapt the API as the UI requires, while also simplifying process of lining up release of both the client and server components. — Sam Newman
Why we need BFF & What problems we are solving?
Context:
Imagine we are building an online store that uses the Microservice architecture and that we are implementing the product page.
We need to develop multiple versions of the product details user interface:
- Web
- Mobile
- Tablet
- 3rd Party Integration API
Since our online store uses Microservices architecture, Our user interfaces are calling multiple services for the information.
Situation:
- The granularity of APIs provided by microservices is often different than what a user interface needs.
- Different user interface need different data. For example, the web browser version of a product details page is typically more elaborate then the mobile version.
- Network performance is different for different types of user interface.
- Partitioning into services can change over time and should be hidden from user interfaces.
- Services might use a diverse set of protocols.
Solution:
A BFF is created as an interface between each API consumer and a shared API or data resource. The BFF implements API logic that is specific to that particular application. It’s essentially a translation layer that ensures data is transformed specifically to suit the needs of that particular client. Clients might be using multiple APIs, in which case, the BFF can also act as an API gateway that is defined just for a single application. It will perform the task of aggregating and combining all the data from a set of APIs into a common format that is convenient for the client.
What are the benefits of this? Firstly, it’s easier to adopt the API as UI requirements change. As a frontend developer, now instead of having to wait for the API team to create a particular endpoint for you or integrate a new field, or a new set of data, you now have the power to just go ahead and make those changes yourself. It also simplifies the process of lining up server and client releases. Now that one team manages both the UI and the API, there’s no longer coordination that has to happen between a frontend and a backend team. Thirdly, because it’s focused, the BFF API will be smaller than the shared single purpose API. It’ll probably be easier to understand and navigate and will probably have smaller payloads if it’s a REST API. Finally, you’re able to aggregate multiple calls to downstream APIs into a single call to the BFF, which is a lot simpler and often more performant.
- An API Gateway/BFF is the single point of entry for any microservice call.
- It can work as a proxy service to route a request to the concerned microservice, abstracting the producer details.
- It can fan out a request to multiple services and aggregate the results to send back to the consumer.
- One-size-fits-all APIs cannot solve all the consumer’s requirements; this solution can create a fine-grained API for each specific type of client.
- It can also convert the protocol request (e.g. AMQP) to another protocol (e.g. HTTP) and vice versa so that the producer and consumer can handle it.
- It can also offload the authentication/authorization responsibility of the microservice.
One or More BFF?
so how many BFF(s) should you go for? The BFF pattern recommends building one API per client. That means that each frontend essentially has its own custom API, which is built and maintained by the same team as the frontend.
Conclusion:
BFF offers a good way to enable teams building different client-facing apps to be in charge of their own destiny. This autonomy is crucial to iterate quickly on the client apps and deliver good experience/features fast. By supporting change, BFF supports evolutionary design and moves the whole system into a better, less-coupled state and then a big single purpose API.
Thank you for reading 
