BFF, short For Backends For Frontends, is a back-end application that serves the front-end of services to solve the service coupling problem of multi-access terminals.

In micro service architecture company recently met with some of the problem of terminal access interface, different terminals have different interface service, has the ability to different operating data, made a research for this kind of business scene, whether we can be in different business logic to handle access layer, obtain different data content?

As early as the emergence of microservices, there have been similar business requirements, and derived a mature solution, that is, BFF, which can provide corresponding service interfaces for different business scenarios, and each business scenario is completely independent.

The evolution process

In traditional applications, we typically only provide interfaces to one type of terminal.

Single-end invocation of the underlying service

The interface provided in the traditional application program is business-specific, and it is troublesome to provide this type of interface independently to other systems for reuse, which is determined by the high coupling at the early stage of design.

Multiple direct calls to the underlying service

If our interface is provided to both web and mobile terminals, the mobile terminal is only used to collect data and display data, while most scenarios of the Web terminal are used to manage data, because the business of different endpoints is different, the interface reuse of each terminal is not too high.

Multiple ends share a BFF

Shared service interface for multiterminal scenario, we will be the basis of data service and BFF separation, data services provide data only add and delete, not too much involved in the business processing, all business judgment to BFF to control, some abnormal business logic is also handled by BFF formatted after show an endpoint.

This design approach also has certain problems. Although the basic service and BFF are separated, we only need to conduct business judgment processing at the BFF level, but the sharing of a BFF by multiple ends will lead to increased code writing complexity, decreased code readability and multi-end business coupling.

Each end provides a BFF

If we provide a BFF for each endpoint, each endpoint’s BFF handles its own business logic, fetching data from the underlying service when needed, and then assembling the data to instantiate the returned object before the interface returns it.

In this way, if new functions are added to the basic service, BFF will hardly be affected. If we split the App endpoint into Android and IOS, we only need to split app-BFF into Android-BFF and ios-bFF, and the basic service will not be affected

In this way, whenever a new access endpoint is added, we only need to modify the forwarding of the gateway and add a BFF. We can completely reuse the service interface provided by the basic service, because the interface provided by the basic service is not business specific!!

conclusion

In microservice architecture design, BFF plays a key role in business aggregation. Basic services can be called by OpenFeign and restTemplate to obtain data, and the obtained data can be assembled to return the result object. BFF solves the problems of business scenarios and also brings some problems, as shown below:

  • Latency of response time (The latency is lower if the service is inter-intranet access)
  • Time-consuming to write (extra code because of the layer of forwarding added to the base service)
  • Business exception handling (unified formatting of business exception returns)
  • Distributed transactions (a common problem with microservices)