Backends For Frontends

Why

• There were single apis created to serve all client types, that lead to

  • Diverse UI requirements

    • Mobile devices have different constraints and interaction patterns compared to desktop applications, necessitating different data and functionalities.

  • Increased Complexity:

    • A single API must accommodate various client needs, leading to bloated and complex codebases.

  • Deployment Bottlenecks

    • Changes required for one client type can impact others, slowing down development and deployment cycles.

What

• creating a separate backend service for each client type (e.g., web, iOS, Android). Each BFF is tailored to the specific needs of its corresponding UI

• a single UI action might require data from multiple services. The BFF can aggregate these calls, reducing the number of requests the client must make and handling complexities like error management and data transformation

Benefits

• Customized API:

  • Each BFF can offer an API optimized for its client, improving performance and user experience.

• Team Autonomy:

  • Frontend teams can develop and deploy their BFFs independently, reducing dependencies and coordination overhead.

• Simplified Maintenance:

  • Smaller, focused codebases are easier to manage and evolve over time.

Issues

• Code duplication

  • But rather have this than tight coupling

  • When necessary, shared functionality can be extracted into separate services or libraries, but only when it provides clear benefits

When to use

• Different clients have distinct requirements that a general-purpose API cannot efficiently serve.

• Frontend and backend teams need to work independently to increase development velocity.

• You want to encapsulate and manage the complexity of aggregating multiple backend services.

Links

• https://samnewman.io/patterns/architectural/bff/

• https://blog.bitsrc.io/bff-pattern-backend-for-frontend-an-introduction-e4fa965128bf

• https://www.thoughtworks.com/insights/blog/bff-soundcloud