Understanding API gateway
If you're working on a microservices architecture with multiple services and would like to expose your APIs to external developers, several requirements need to be considered.
These requirements include
Authentication: Authentication is the process of verifying the identity of the user or system trying to access the APIs. An API gateway can apply authentication mechanisms such as OAuth2, JWT, or API keys to ensure that only authorized users or systems can access the APIs.
Rate Limitation: Rate limitation is the process of limiting the number of requests that a user or system can make to the APIs within a certain time period. An API gateway can enforce rate limits on a per-user or per-service basis to prevent overload on the underlying microservices.
Transformations on the request/response layer: Transformations on the request/response layer involve modifying or transforming the incoming requests and outgoing responses to the APIs. An API gateway can apply transformations such as message routing, filtering, content-based routing, or payload modification to ensure that the requests and responses are in the expected format and are compatible with the underlying microservices.
Different quotas based on developer types: Different quotas based on developer types involve setting different limits on the number of requests or resources that a user or system can access based on their membership level. An API gateway can provide different quotas for standard developers and premium developers, for example, by limiting the number of requests, the amount of data retrieved, or the frequency of API calls.
Different APIs are exposed based on developer types: Different APIs exposed based on developer types involve providing different sets of APIs to different users or systems based on their membership level. An API gateway can expose different APIs for standard developers and premium developers, for example, by hiding some APIs from standard developers and exposing more APIs to premium developers. This can be useful in monetizing the APIs and providing different levels of service to different customers.
Customize API that can mix all microservices complex logics and return output to make the external developer's life easier. In a microservices architecture, there may be several services that an external developer needs to access in order to complete a task. For example, a developer may need to interact with one service to retrieve user data, another service to retrieve product information, and yet another service to complete a transaction. To simplify this process, an API gateway can be configured to expose a separate API that combines all microservices and returns output to external developers. This separate API acts as a facade, hiding the complexities of the microservices architecture from external developers and providing a simpler interface for them to use. The API gateway takes care of routing requests to the appropriate microservices and aggregating their responses into a single output. This means that external developers can interact with a single endpoint and receive the necessary information from all the connected microservices.
To fulfill these requirements, an API gateway can be used to securely expose your APIs to external developers. By using an API gateway, internal services do not need to write these logics at their end. Instead, the API gateway will take care of all the requirements, such as managing authentication and rate limitations, applying transformations on the request/response layer, and providing different quotas and APIs based on the developer's type.
API Gateway can also perform additional functions, such as caching, logging, and monitoring. In addition, API Gateway provides API lifecycle management, which includes tasks such as creating, testing, deploying, versioning, and retiring APIs. By managing the API lifecycle in a centralized way, API Gateway can help ensure that APIs are developed, deployed, and retired consistently and in a controlled manner, reducing the risk of errors or security issues.
Understanding BFF
BFF, or Backend For Frontend, is an API gateway that is designed to serve front-end clients only. In a microservices architecture, there may be several internal services that a front-end or mobile application needs to access in order to create views that combine information from multiple services.
By introducing a BFF layer, you can take advantage of several benefits:
You can write all your front-end related logic in the BFF layer. This means that the internal microservices can remain focused on their core functionality, while the BFF handles any front-end-specific logic.
The BFF layer can act as a facade for the internal microservices, exposing a unified API that is tailored to the needs of the front-end application. This can simplify the front-end code and reduce the number of network requests needed to create a view.
You don't need to expose your internal services to the public. By routing all requests through the BFF layer, you can keep your internal services behind a firewall and only expose the BFF to the outside world.
Writing a BFF layer can help you manage authentication at the BFF level. While authorization may still need to be handled at the service level, the BFF layer can handle authentication for all requests, making it easier to manage security.
The BFF layer can also act as a filtering layer, allowing you to restrict which data is exposed to the front-end application. This can be particularly useful if your internal services expose data that should not be returned to front-end clients. By routing requests through the BFF, you can control which data is returned to the client, while still allowing internal services to function as intended.
One question that often comes up is whether introducing a BFF layer will create latency. While it is true that the BFF layer adds an extra hop in the request/response chain, the network latency can be reduced by batching multiple requests together and reducing the number of network calls that need to be made by the front-end application. Additionally, the BFF layer can cache responses and handle load balancing, further reducing latency and improving overall performance.
API-gateway vs BFF
API Gateway acts as a middleman between your internal microservices and external clients. Its main job is to provide a single interface for external clients to access your microservices while taking care of tasks like authentication, rate limiting, and routing requests to the right microservice. Additionally, API Gateway can perform other tasks like caching, logging, and monitoring.
BFF, on the other hand, sits between your internal microservices and your front-end clients, like mobile or web applications. Its main purpose is to simplify the front-end code by acting as a façade for your microservices and providing a tailored API that meets the needs of your front-end application.
In summary, while API Gateway is designed to handle external clients and provide a unified API to multiple types of clients, BFF is designed to handle front-end clients only and simplify the front-end code. Both API Gateway and BFF can help you manage and expose your microservices securely and efficiently, but they serve different purposes and are tailored to different types of clients.
References
https://samnewman.io/patterns/architectural/bff/#comment-2923121019
https://kuroco.app/blog/api-management/2022/05/05/api-gateway-vs-backend-for-frontend/
https://medium.com/@abhilashjn85/bff-layer-when-its-more-than-just-an-api-gateway-4679da49534c