Backend For Frontend (BFF)

Introduction

In a tipical development, the frontend application consumes data from a backend API. The backend API is designed to be generic and serve multiple clients which can lead to a situation where the frontend application needs to make multiple requests to the backend API to get all the data it needs. This can lead to performance issues and a poor user experience. Aditionaly, the data returned by the backend API may contain more data than the frontend application needs or data that is not in the format that the frontend application expects.

Backend For Frontend

To solve these issues, you can create a dedicated backend which is optimized for the specific needs of the frontend application. This dedicated backend is called Backend For Frontend (BFF). In this backend you can extend the API with new properties, reduce the amount of data or join data from multiple sources to reduce the number of requests from the frontend application.

Example with a single service

Let’s say you want to add to a frontend application a list that displays cron jobs. The backend API is already created and returns a list of cron jobs with the following properties:

1
[
2
  {
3
    "id": 1,
4
    "name": "Backup",
5
    "status": "running",
6
    "cronExpression": "0 0 * * *"
7
  },
8
  {
9
    "id": 2,
10
    "name": "Cleanup",
11
    "status": "stopped",
12
    "cronExpression": "0 1 * * *"
13
  }
14
]

But bussiness requirements says that the frontend application should also display the next execution time of each cron job and a human readable description of the cron schedule.

Without BFF

The frontend application needs resolve a next execution time and a human readable description of the cron schedule by itself. Parsing cron expression is not a trivial task and moreover the description should be translated to a user language. At the end you will end with a library to parse cron expressions and another library to translate cron expression to the human readable form. This will increase the bundle size and the complexity of the frontend application.

• cron-parser - 26.3kB (Minified + Gzipped)
• cronstrue - 5.6kB (Minified + Gzipped)

1
import cronParser from "cron-parser";
2
import cronstrue from "cronstrue";
3

4
// somewhere in the frontend application
5
function getCronDetails(cronExpression) {
6
  const nextExecutionTime = cronParser.parseExpression(cronExpression).next().toString();
7
  const humanReadableCronExpression = cronstrue.toString(cronExpression);
8

9
  return { nextExecutionTime, humanReadableCronExpression };
10
}

With BFF

With BFF you can extend the API with the next execution time and the human readable name of the cron expression and return excatly what the frontend application needs. Of course you still need to handle calculations and translations but at least you can do it in the backend without increasing the bundle size and the complexity of the frontend application.

1
import express from "express";
2
import cronParser from "cron-parser";
3
import cronstrue from "cronstrue";
4

5
const app = express();
6

7
// BFF logic
8
app.get("/crons", async (req, res) => {
9
  const cronList = await fetch("https://cron-api.example.com/crons");
10

11
  const cronJobsWithExtraProperties = cronList.map((cronJob) => {
12
    const interval = cronParser.parseExpression(cronJob.cronExpression);
13
    const nextExecutionTime = interval.next().toString();
14
    const humanReadableCronExpression = cronstrue.toString(cronJob.cronExpression);
15

16
    return {
17
      ...cronJob,
18
      nextExecutionTime,
19
      humanReadableCronExpression,
20
    };
21
  });
22

23
  res.json(cronJobsWithExtraProperties);
24
});

Example with multiple services

Let’s say you want to create a list of products in a frontend application. We have many services in the architecture that provide data about products. The first service provides data about the stock of the products, the second service provides static data about the products and the third service provides translations.

As you can see to get all the data needed to display a list of products in the frontend application you need to make multiple requests to multiple services. Of course you can do it in the frontend application but it will increase the number of requests and perhaps the frontend application will need to handle the translations and join the data from multiple sources. You can resolve those issues by creating a decidated endpoint just for displaying a list of products in BFF service.

1
import express from "express";
2

3
const app = express();
4

5
app.get("/products-list", async (req, res) => {
6
  const ids = req.query.ids.split(",");
7
  const languages = req.query.language;
8

9
  const [stockData, staticData, translations] = await Promise.all([
10
    fetch(`https://products-api/products?ids=${ids.join(",")}`),
11
    fetch(`https://products-static-data-api/products-static-data?ids=${ids.join(",")}&language=${language}`),
12
    fetch("https://translations-service/translations"),
13
  ]);
14

15
  const productsList = stockData.map((product) => {
16
    const productStaticData = staticData.find((el) => el.id === product.id);
17

18
    return {
19
      id: product.id,
20
      price: product.price,
21
      stock: product.stock > 0 ? translations["In Stock"] : translations["Out of Stock"],
22
      title: productStaticData.title,
23
      mainImage: productStaticData.images[0],
24
    };
25
  });
26

27
  res.json(productsList);
28
});

Pros

• Optimize the API for the specific needs of the frontend application.
• Reduce the amount of data returned by the backend API.
• Join data from multiple sources to reduce the number of requests from the frontend application.

Cons

• Increase the number of services in the architecture.
• Increase the complexity of the architecture.
• Increase the maintenance cost.

Q&A

Which language should I use to create a BFF?

You can use any language that you are comfortable with but if I would recommend using the same language as the FE application. Thanks to that you can share the code (and libraries!) between the FE and BFF.

Should I create a separate repository for the BFF?

Not really. Having a mono-repo with the FE and BFF can simplify the development process. When you need to make changes in the FE and BFF at the same time you can do it in a single pull request (it is especially useful when you need to break a contract between the FE and BFF). It is also easier to keep the versions of the FE and BFF in sync.

About about GraphQL?

GraphQL is a alternative to BFF. When you use GraphQL then you should not need a BFF.