API Gateway vs Backend For Frontend (BFF) — Everything you need to know
Hello everyone. In this article, we are going to see what is an API Gateway 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 when we need API GW vs BFF. Let's get started.
What is an 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
A reverse proxy is a server component that sits in front of web servers and
they are responsible for forwarding the client requests to those web servers
and send the response back to the client
A reverse proxy provides an additional level of abstraction and control
to ensure the smooth flow of network traffic between clients and servers.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.
Client to Microservices Communication without using API Gateway
Let us look at a scenario in the microservices architecture without an API Gateway. In the below diagram, the clients directly communicate with the microservices without any API gateway involved.
There are a lot of drawbacks there.
- If the Microservices grow bigger and the system becomes more complicated, then the client has to remember each and every endpoint
- The client must make a lot of API calls to different microservices to load the data which could increase the latency and may not provide a good experience to the user
- As discussed above, cross-cutting concerns like Authorization, logging, Caching, etc must be implemented in every microservice
- Usually, Microservices will not have internet connectivity and they would be placed inside private subnets with private IPs. Opening up Microservices to the public is asking for trouble from attackers.
- The Clients may not be able to communicate with microservice that only supports specific protocols like AMQP or Binary protocols
Client Server Communication using API Gateway in Microservices Architecture
We have seen a lot of drawbacks without using an API Gateway in a Microservices architecture. To eliminate those drawbacks and make our lives convenient, we definitely need an API Gateway as a layer between the Client and the Services
Benefits of API Gateway
The API Gateway can do a lot of things and let us look at the benefits below
1. Abstracting the clients from the complexity of the backend system
2. Handling Authentication and Authorization of users in a single place for the entire system
3. Transforming the requests and responses according to the format needed
4. Rate limiting for each of the APIs to prevent the load on backend services
5. Throttling the API requests made by a single user to prevent the DDOS attack
6. Reducing the load on the services by Caching the responses for the repeated requests
7. Supports different protocols
8. Metering individual APIs to make billing the clients based on usage
9. Logging and tracing the API calls into the system in a single place
10. Error handling
11. Aggregating the data across microservices and respond the data to the client on a single API call. This will avoid multiple API calls the clients need to make
Drawbacks of API Gateway
Every good thing comes with drawbacks and so is the API Gateway
- The API Gateway can become a single point of failure for the entire system.
2. It could cause performance issues and increase the latency of API calls if we perform too many things in the API Gateway.
3. If we have too many microservices, managing too many routes could get complicated
4. There is always an extra hop on API calls from the client to the server.
5. Extra cost because of the additional server component involved
What is Backend for FrontEnd (BFF) Pattern?
We saw in detail about API Gateway and this approach is fine if we have a single client like 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. This could get bigger and could bloat up the API Gateway service by making it a single big 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 as 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 of 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.
When to use API GW vs BFF?
Well, this is an open question and it completely depends on the organization.
1. If the application is new, we would not be knowing about its usage in advance. So, initially, the API Gateway can be a single component and once the usage increases across the clients, then the APIs for clients could be moved into individual components i.e BFF
2. If the different clients need a different type of Authentication, definitely better to go for BFF rather than using a single API GW
3. If the client applications are owned by different teams, then it will make sense to use BFF else there would be a lot of interaction and overhead when we have a single API GW
In this article, we saw what is an API Gateway and saw the scenarios for Client to Microservices communication with and without the API Gateway. We also looked at the benefits and drawbacks of the API Gateway pattern. Then we looked at a pattern called Backend for Front End, which is a variant of the API Gateway pattern, and concluded the article by looking at when we need to use API GW vs BFF
Hope you enjoyed reading this and thanks for reading this!!!
If you like to get more updates from me,
please follow me on Medium and subscribe to email alert.
If you are considering to buy a medium membership,
please buy through my referral linkPlease go through my below article if you wanted to know about Spring Cloud Gateway
