Skip to content

Latest commit

 

History

History
58 lines (49 loc) · 3.15 KB

Backends_For_Frontends.md

File metadata and controls

58 lines (49 loc) · 3.15 KB
Raw

Backends For Frontends (BFF)

Motivation

  • The requirements are significantly different for serving different frontends.
  • One generic backend has too much logic.
  • One generic backend needs to be managed by separate teams.

Solution

Concepts

  • Restricts the use of backends (BFFs) to one specific user interface or application.

Implementation

  • A single call in to a BFF results in multiple downstream calls to microservices.
  • Number of BFFs
    • Options
      • One BFF per type of client. For example, Android and iOS will have different BFFs.
      • One BFF per type of user interface. For example, Android and iOS will have the single mobile BFF.
    • Recommendation
      • BFFs should align around team boundaries. Team structure should drive how many BFFs you have. It can reduce the chance of cross-team coordination.
  • BFFs should only contain client-specific logic and behavior. General business logic and other global features should be managed elsewhere in your application.

Pros & Cons

Pros

  • Each BFF is smaller, less complex and faster than one generic backend.
  • Each BFF is isolated from others.
    • Each BFF can have different processes.
    • Each BFF is independently scalable.
    • Each BFF can be released independently.

Cons

Consideration

Topic Consideration Possible Solution Options
Code Reusability Code duplication across BFFs is highly likely
  • Consider to use the same technology stack for all BFFs.
  • Consider to extract common functionalities into a shared library so that all the BFFs can use them.
  • Consider to extract common functionalities into a new standalone service.
    		•

    When To Use

    The application needs to provide specific functionality for a mobile UI or third party.

    References