no time, jump straight to conclusion
In software development, engineers are constantly seeking innovative solutions to streamline application development. One such pattern that has gained prominence in recent years is the Backend For Frontend (BFF) pattern. In this blog post, we’ll delve into the intricacies of BFF, explore its similarities with API Gateway, and discuss the advantages and disadvantages of incorporating business logic and other microservice cross cutting concerns into a BFF implementation.
Understanding the BFF Pattern
The BFF pattern, coined by Phil Calcado at SoundCloud (initially proposed as BEFFE, later BFF), advocates for the creation of specialized backend service(s) tailored to the unique needs of individual frontend applications. This approach recognizes that different user interfaces often require specific data and functionality. Using the BFF pattern, software engineers can optimize the communication between the frontend and backend, ensuring a more efficient and responsive user experience as well as separating concerns.
BFF & API Gateway Pattern
While BFF and API Gateway serve distinct purposes, they share commonalities in their communication between frontend and backend services. In fact, the BFF pattern is a specialization of the API Gateway.
Striking Similarities
Both patterns act as intermediaries, serving requests and responses between clients and backend servers. Both, API Gateways and BFFs, provide a centralized point for managing and securing APIs frontends use, enabling developers to enhance performance and scalability.
Exciting Differences
The primary distinction between API Gateway and BFF pattern is scope and purpose.
API Gateways are often deployed to aggregate and manage multiple backend APIs, serving as a gateway for various backend services. In contrast, BFF(s) are tailored to be the single backend service surface for the frontend(s) they are serving. There are two flavors of the BFF pattern.
- One BFF service can serve all frontends with a software landscape including desktop clients, tablet and smartphone clients that run iOS, Android or Windows Mobile.
- Multiple BFF services can serve different kinds of frontend. Frontends can be also categorized according to their display size (mobile & web). One BFF service could serve all mobile frontends and another web clients.
Business logic
Backend services often implement business logic that frontends present to the user.
Suppose there is a backend service that provides catalog information and another backend service produces detailed shopping item information. Also, suppose both services need to perform a validity check of stock keeping units (SKU). Some engineers may abstract this SKU validation logic into a central component.
Candidates to abstract and extract this logic to are:
- a library
- a (micro) service
- (one of) the BFF service(s)
Considering the the rule of three is often a good idea when extracting (business) logic into a central component or service. Lets see if BFF is the best location for that.
What about shared business logic in BFFs?
The initial BFF post includes an example about multiple user profile pages. Their conclusion was to create a separated UserProfileService and not add this logic to one or multiple BFF service(s).
You need to balance advantages and disadvantages of adding shared business logic in BFFs. In my experience, the conclusion was always to separate business logic from BFF services. Maintenance and complexity that resulted from broken separation of concerns caused additional effort. The effort was even higher, when business logic has to maintain state (stateful). Stateful services contain an additional layer of complexity about elasticity (scaling in and out).
These are general considerations I’d consider about adding share business logic to BFFs:
- Complexity: In a microservices environment, incorporating business logic into BFFs might blur the boundaries between services, potentially impacting the separation of concern and subsequent qualities.
- Potential Overhead: Depending on the size and complexity of the frontend application, implementing business logic in BFFs may introduce additional overhead, affecting overall performance.
Cross cutting micro service concerns
Authentication & Authorization are classical concerns that often concern multiple (micro) services.
- Authentication is the act of validating that users are whom they claim to be.
- Authorization in system security is the process of giving the user permission to access a specific resource or function.
Similar to the business logic example above, authentication & authorization is an important concern that contains its own complexity (e.g. JWT token or cookie management). Given this complexity these concerns allow for a dedicated (micro) service.
Conclusion
The BFF software architecture is a specialization of the API gateway pattern. BFF services are specialized backend service(s) tailored to the unique needs of individual frontend application(s). Don’t dilute this purpose with additional requirements or functionality.
Leave a Reply