How API Gateways and Backend For Frontend (BFF) Patterns Have Evolved

Let's explore some key architectural concepts from the journey of a company that has just launched its product.

Chapter 1: The Monolithic Beginning

The company began as a small startup with a simple web application for task management.

[Web Frontend] <-> [Monolithic Backend]

As the user base grew, the development team expanded the application's features. The monolith became increasingly complex and difficult to maintain.

Chapter 2: The Move to Microservices

To address scaling issues and improve development agility, The company decided to break its monolith into microservices:

[Web Frontend] <-> [Service A] [Service B] [Service C] …

This solved some problems but introduced new challenges:

1. The front end had to manage multiple API endpoints.

2. Each service had its own authentication mechanism.

3. Monitoring and logging became more complex.

Chapter 3: Introducing the API Gateway

To solve these issues, The company implemented an API Gateway:

[Web Frontend] <-> [API Gateway] <-> [Service A] [Service B] [Service C] …

The API Gateway:

• Provided a single entry point for the frontend

• Handled authentication and authorization

• Managed logging and monitoring

• Performed simple request routing

This architecture worked well as The company continued to grow.

Chapter 4: Mobile App and New Challenges

The company decided to launch a mobile app. Initially, both web and mobile frontends used the same API Gateway:

[Web Frontend] --\
[Mobile App] ---> [API Gateway] <-> [Microservices]

However, problems soon emerged:

1. The mobile app required different data shapes than the web app.

2. Mobile networks needed more optimized payloads to reduce data transfer.

3. The mobile app had unique requirements for push notifications and offline functionality.

The generic API Gateway was not optimal for addressing these client-specific needs.

Chapter 5: Embracing the BFF Pattern

To solve these client-specific issues, The company adopted the Backend for Frontend (BFF) pattern:

[Web Frontend] --------> [Web BFF] -------\
[Mobile App] ----------> [Mobile BFF] ----> [API Gateway] <--> [Microservices]
[Desktop Client] ------> [Desktop BFF] ---/

Each BFF was tailored to its specific frontend:

1. The Mobile BFF optimized payloads for mobile networks and handled mobile-specific concerns like push notifications.

2. The Web BFF aggregated data from multiple services to reduce front-end calls.

3. The Desktop BFF managed long-polling for real-time updates needed in the desktop application.