Overview

This is a summary of what I researched about BFF.

What is BFF

BFF stands for Backends For Frontends. It is not Best Friends Forever.

As the name suggests, it is a backend server for the frontend, responsible for responding with APIs or HTML for the frontend, playing a role in UI/UX.

BFF can solve the problem of addressing the diversity of clients (the callers of the server) by organizing the requirements for each client.

Points of Interest

Programming Language
- Since BFF is a backend for the frontend, it often seems to be composed of frontend-oriented technologies.
Reconfiguration
- Once you make it a BFF, it seems difficult to dismantle.
- It might be better to postpone adopting BFF until it is truly necessary (though determining if it is truly necessary is not easy...)
Possible Anti-patterns
- Lack of communication between backend and frontend engineers
- Too much non-UI logic on the BFF
- A big bang joint that combines backend and frontend all at once
Ease of Frontend Optimization
- Optimizing API calls could improve UI display performance.
BFF and DDD
- Is domain organization on the frontend necessary? I'm not sure about this...
API Aggregation Units
- There seems to be difficulty in deciding how to group APIs.
- If you're doing microservices, setting up another microservice instead of a BFF might be better, which could undermine the benefits of BFF.
Compatibility with Micro Frontends
- I have no knowledge of micro frontends, so I don't understand anything.
- It might be influenced by the component structure of micro frontends?
Good Compatibility with GraphQL
- If using GraphQL, code-first rather than schema-first is more suitable according to some cases.
  - cf. Why unify GraphQL to code-first? BFF/FE reorganization for consistency in type definitions)
Availability
- Since BFF aggregates multiple backends, it is affected by and dependent on the failures of multiple backends.
- Regarding this concern, ZOZO seems to have devised a way to respond only with data that can be returned correctly.
  - cf. Started Backends For Frontends (BFF)
Caching
- Caching on the BFF side also needs to be considered.
Timeout and Retry Control
- Although it's a consideration for regular APIs, adjusting settings for BFF might be a bit tricky.
Deployment
- It seems necessary to coordinate the deployment of BFF and backend.
- It affects the speed of delivery.
No Business Logic
- It seems basic for BFF not to have business logic, but can business logic be completely separated? There might be cases where it can't.

References

Impressions

I initially thought I would just skim through BFF since I already knew about it, but there were many interesting points to consider, such as architecture availability, handling business logic, appropriate client aggregation, and its relation to organizational structure.

Personally, I feel that BFF has many potential pitfalls if not approached cautiously. While I can see the traps, it seems challenging to build it in a way that avoids them.

If I ever have the opportunity to consider BFF, I plan to reflect on this.