Skip to main content

Backend for Frontend (BtF)

The following section provides an overview of BfF (Backend for Frontend), including its core library implementation and basic concepts related to customizing BfFs, building BfFs, and creating dashboards with widgets.

What is BfF?​

BfF stands for Backend for Frontend. It refers to a design pattern where developers create a specialized backend (server-side) that is specifically tailored to meet the needs of a particular frontend (client-side) application. The main purpose of using the BFF pattern is to optimize communication between the front-end and the back-end by providing a back-end that is tightly coupled to the requirements of the frontend.

Traditionally, web applications have a monolithic backend that serves multiple clients, which can include web browsers, mobile applications, and other clients. However, as front-end applications have become more complex and diverse, it has become clear that a one-size-fits-all approach to the backend can lead to inefficiencies and increased complexity in handling different client requirements.

With the BFF pattern, a dedicated backend is developed to serve a specific frontend, ensuring that the backend's APIs and data formats are customized for the frontend's consumption. This gives front-end developers more control over the data they need and how it is delivered, potentially improving performance and user experience.

Using BFF doesn't mean that the main backend for the entire system disappears. Instead, it becomes responsible for handling shared functionality and serving other clients that do not require the specific optimizations of the dedicated BFF.

The BFF pattern is commonly used in microservices architectures, where services can be designed and scaled independently, allowing teams to focus on their specific areas of expertise without tightly coupling frontend and backend development.

Using the BfF pattern has several advantages over not using it:

  • Filtering: Clients get exactly the data they need, optimizing data transfer and consumption.
  • Aggregation: The need for multiple client requests is minimized, resulting in significant performance improvements by reducing expensive connection opening operations.
  • Caching: Re-aggregated requests are not loaded unnecessarily, resulting in efficient handling of "304 Not Modified" responses.
  • Data Hiding: Sensitive tokens or information required for backend interactions can be hidden from the client, improving security and privacy.
  • Microservices: BfF represents a first step in moving from a monolithic backend architecture to a more scalable and modular microservices architecture.

FAQ​

  • Do I need a BFF if I'm developing a widget? – No, you don't need. Because its implementation can be specific, and you don't know how everything works there. From the widget's point of view, the widget cannot directly modify the BFF, that is handled by the core functionality of the platform. So if you are developing a widget, the only thing you can know is the BFF specification - the grid density, and the second thing is the mechanics of saving settings.
  • I owner of the platform, do I need BFF? – Yes, you do. Because BFF performs customization functions of storage. In BFF, you can store information that is not convenient to store at runtime.
  • Can I modify BFF? – Yes, you can.
  • Can I host BFF by myself? – Yes, you can.
  • Can Invent host BFF? – Yes, it's possible.