In recent days, system development based on web application (web UI) is increasingly popular. There are enormous advantages for delivering UI on the web platform. It also reduces installation costs significantly. However, due to the development of mobile devices that causes the need for using those devices increases everyday, so multiple platforms development is also necessary. Therefore, developers likely use backend API for many platforms (general purpose API) to minimize development costs and resources.
A general-purpose API backend
Utilizing the general backend API leads to many challenges because the number of users and the need for supporting platforms keep increasing:
Retrieving unnecessary data on mobile devices because the API was initially designed for desktop web UI
Implementing many complex calculation functions on the front-end side to ensure accurate data presentation on various platforms
Working on the same API with multiple UI teams and changing requests frequently which may cause bottlenecks
Maintaining the code becomes more challenging because numerous lines of code were created
Common Team structures when using A generic backend API (from samnewman.io)
Instead of using general-purpose API, we will have a concept of developing niche backends for each user experience. It is called Backends for Frontends (BFF). It was first described by Sam Newman and was used by REA and SoundCloud.
Backends for Frontends (BFF) is a pattern that tailors APIs for different clients or user interfaces such as web, mobile, or other platforms. Instead of having a single API for all clients, BFFs provide customized APIs that cater to personal needs and requirements of each client. This will help ensure efficient communication and an optimized user experience.
Using server-side BFF per frontend
Using server-side BFF for some frontends
A single BFF focuses on a single UI, and that UI only. This allows it to be focused, and as a result, it will be smaller.
These are some advantages of using BFF:
Improved Performance: BFF allows developers to optimize API requests and responses for each front end by customizing the API to the specific needs of the front end. This will help reduce over-fetching or under-fetching of data and minimize the amount of unnecessary data transferred between the front end and back end.
Security: BFF handles authentication and authorization logic to ensure that each frontend receives only the data that was allowed to access.
Flexibility: BFF helps developers to make changes or updates to a specific frontend without affecting the others. This flexibility is enormously helpful in large, complex applications with multiple user interfaces.
Token management: BFF can handle the generation, validation, and management of authentication tokens or session management for each frontend.
Single Sign-on (SSO) integration: BFF can manage the authentication and token exchange with the identity provider. This benefit makes it easier to implement and maintain SSO functionality.
Reduced Network Overhead: BFF optimizes the data transfer. For that reason, it can lead to faster loading times and produce a more responsive application, particularly in low-bandwidth or high-latency situations.
Testing and Debugging: BFF simplifies testing and debugging efforts, as you can focus on specific front-end requirements and scenarios. This reduces the complexity of testing and makes it easier to identify and fix issues.
There are several approaches to implementing BFF when you have multiple platforms with the same user experience:
As Sam Newman suggested: “If the iOS and Android experiences are very similar, then it is easier to justify having a single BFF. If however, they diverge greatly, then having separate BFFs makes more sense."
Different mobile platforms, and different BFF, as used at REA
Having one BFF for different mobile backends, as used at SoundCloud
Consider the example below:
We have an application for an e-commerce company. We want to show user’s wishlist. We have multiple services that hold the pieces of information that we want, in which some services depend on other services (ID, name,...). Ideally, we will likely run the calls to other services simultaneously to reduce the overall call time. However, we will be unable to do anything if one of the services is down!!!
BFF resolves that issue by managing all calls in one place. The only thing we need to do is to make sure that the client makes the call to the BFF.
While an API Gateway is a single entry point for all API calls from all clients to fetch data from the system, a BFF is only responsible for a single type of client.
API Gateway
BFF
BFF and API Gateway are not mutually exclusive concepts. They can be used together in a complementary manner to address different concerns in a modern application architecture.
Since we have multiple clients, we may implement some authentication/authorization protocols in Javascript. However, this is no longer recommended for some reasons.
Using access tokens in the browser has more security risks than using secure cookies.
Storing something securely in the browser for a long time is risky as it can be stolen by various attacks.
BFF can resolve these issues by creating a layer that handles the token on the server side. In this way, we can still use session cookies or tokens in case of mobile devices.
We can see more detail in the example from the next section.
Next.js is a full-stack framework where you can have client-side and server-side code in one app.
First of all, create a separate API route in Next.js to handle authentication, authorization and user-specific data retrieval.
In Next.js application, call the BFF API route to handle and fetch user-specific data.
Here is the final result:
In this example, the `/api/bff` route handles user login and issues a JWT token. Then Authorization header is used to pass the token when making requests to the BFF.
Author: Melvin
.png)