Comparison of similarities and differences of an API gateway vs BFF
An API gateway is a single point of entry for all clients fetching data from the system, while a backend-for-frontend (BFF) is tailored to a specific frontend - typically with multiple BFFs corresponding to multiple frontends. However, to better understand the reasoning behind each approach, it is worth considering their differences.
What is an API Gateway?
An API gateway is essentially the filter through which all clients must pass when trying to access resources within the system. To quote Redhat.com:
“An API gateway acts as a reverse proxy to accept all application programming interface (API) calls, aggregate the various services required to fulfill them, and return the appropriate result.”
How is a BFF Different from an API Gateway?
A BFF is actually a type of API Gateway. In fact, both perform the same function, with the main difference being in scope - or how many clients they interact with. A BFF being tailored to the requirements a specific client, usually a frontend view of an application, while an API gateway genrally functions as a single gateway for the majority (or all) of the clients to access data.
Similarities
Both architectural patterns serve to achieve the same goal at a high level, i.e. decoupling the backend microservices of a system from the frontend clients. This makes it much easier for clients and services with different protocols to interact with each other, without having to duplicate a lot of code for each in order to achieve the same result.
With an API gateway, each client only needs to know the location of the API gateway itself, instead of all the different microservices within the system. The API gateway is able to handle functionality like authentication, and bundling of different microservices resources to be served to the client. A BFF also does this, but on a more granular level.
Differences
As mentioned, the main difference is in how many clients are served. A standard API gateway handles requests from all the clients interacting with the system, while a BFF only handles a specific client. An example would be an app with 2 different frontends:
- Desktop browser web client
- Native mobile client (iOS or Android)
If each of these frontends were given their own dedicated gateway to access resources in the system, i.e. with custom tailored endpoints that would meet their precise needs (as each might require different data depending on the screen size of devices used etc.), then each gateway would be considered a BFF.
Should I Use a Standard API Gateway or BFF?
There are trade-offs to either approach. Generally a BFF pattern is ideal, but it is also more complicated to maintain as it requires more granular customization. A standard API Gateway can also be optimized to function more efficiently on multiple frontends, and essentially 'emulate' a proper BFF architecture in its behavior (with some limitations).
The question largely boils down to a few key factors such as how many clients the application has to interact with, the scale of the application, and the resources the business has to devote to customizing this architecture.
Complex applications with many clients
- May need to support different protocols like GraphQL vs REST APIs serving JSON.
- May have dedicated teams working on each client, with different needs.
- May have an equally complex system of microservices, needing to be bundled/aggregated by gateways before being served to clients.
In the above cases, it may be worth investing the required time and resources into building a proper BFF architecture. This would allow each team that is responsible for a specific frontend to manage their API needs by themselves without having to worry about what other teams are doing. Having a dedicated BFF for each frontend would also ensure they are able to access data resources in the most efficient manner, which is required for the frontend developers work effectively (and not having to constantly be making requests for potentially breaking changes to the backend team).
Alternatively,
Simple applications with only one or a few clients
- May operate with just a single protocol.
- Be managed by a single team.
- Have only a single authentication method for all users.
- Have a relatively simple system of microservices, able to be handled by a single gateway.
In this case, all the API needs of the application can likely be handled by a single API gateway without any issue. It would be overkill to build out and manage multiple BFF gateways, and frontend teams would be able to access the data they need - perhaps not in the most efficient way possible - but without any issue.
Kuroco is the Headless CMS Built with API Management in Mind
Kuroco is a feature-rich headless CMS that enables enterprise teams to easily configure and customize API endpoints. We offer a single API gateway out-of-the-box, which can be easily customized to function similarly to a BFF pattern. This enables you to access all your enterprise's data with ease, without having to make complicated, potentially breaking changes to your backend architecture or do expensive rebuilds.
Kuroco is the best solution of its type for enterprises looking to decouple their backend and frontend concerns. If you are interested in learning more about how our solutions can help your business, please contact us and we will be happy to answer any questions you have.