paint-brush
API Gateway vs Backend for Frontend (BFF): Use Cases, Similarities and Divergencies by@dineshchandgr
7,578 reads
7,578 reads

API Gateway vs Backend for Frontend (BFF): Use Cases, Similarities and Divergencies

by dineshchandgrDecember 15th, 2022
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

Hello everyone. In this article, we are going to see what an API Gateway is and how it is used for Client-Server communication in a Microservices architecture. We will also see the benefits and drawbacks of the API Gateway pattern. Then we will look at a pattern called Backend for Front End, which is a variant of the API Gateway pattern, and conclude the article by looking at cases when we need either method.
featured image - API Gateway vs Backend for Frontend (BFF): Use Cases, Similarities and Divergencies
dineshchandgr HackerNoon profile picture


Hello everyone. In this article, we are going to see what an API Gateway is and how it is used for Client-Server communication in a Microservices architecture. We will also see the benefits and drawbacks of the API Gateway pattern. Then we will look at a pattern called Backend for Front End, which is a variant of the API Gateway pattern, and conclude the article by looking at cases when we need either method.


Let's get started.


API Gateway


The API Gateway is a server that handles many functionalities in a single place for the clients to interact. It also works as a reverse proxy between your client applications and the back-end microservices architecture


There could be multiple clients that call the server APIs, and the API Gateway is the component that routes requests to the relevant microservice and then gets the response and send it to the client. It handles all the cross-cutting features like Security, Logging, Caching, etc in a single place instead of us implementing these functionalities in every single microservices. Moreover, it can consolidate and aggregate the data across aggregating multiple microservices using a single endpoint for clients to communicate.


Before the evolution of Microservices architecture, most of the systems used a Monolith pattern and we could even handle the cross-cutting concerns in a single or couple of servers. But with microservices, we cannot afford to handle cross-cutting concerns in each of the microservices which will make things slower with a larger memory footprint degrading the performance of the system.


Backend For Frontend

We’ve discussed the API Gateway. This approach is fine if we have a single client on the web or mobile. If our application is used by multiple clients like web, mobile, IoT, etc, it is not a good idea to use a single API Gateway for all types of clients. The process will get cumbersome fast and it could bloat up the API Gateway service by making it a single Monolith service.


The better approach for this type of scenario is to use a separate API Gateway for each client type this architectural pattern is called the Backend for FrontEnd (BFF) pattern and it has become a buzzword.


The BFF pattern is an architectural paradigm, a variant of the API gateway pattern and it comprises multiple back-ends that are designed to meet the demands of specific front-end applications, such as desktop, browser, and native-mobile applications, IoT devices, etc.



Also published here.