Decathlon established the Backend For Frontend (BFF) architectural pattern as a company-wide recommendation and provided guidelines for its adoption among engineering teams. The four-part series introduces the pattern and explores its benefits and potential pitfalls. The company also shares alternatives to using the BFF pattern and reviews architectural considerations.
Decathlon is a global retail company with a large technology platform that combines a customer-facing e-commerce platform with many back-office systems. With many web and mobile front-end applications, the company needed help to support the needs of different user experiences on top of its microservices-based backend architecture.
In response to these challenges, the company introduced a Backend For Frontend (BFF) pattern, where a frontend team owns and maintains a backend middleware service, handling orchestration and aggregation specific to supporting its needs. This new abstraction layer allows for a better separation of concerns and greater flexibility with reduced coupling between the system’s components.
Backend For Frontend Pattern (Source: Decathlon Digital Blog)
The BFF layer can accommodate many considerations, including data manipulation/adaptation (API data but also, for instance, image resizing), protocol flexibility (WebSockets, GraphQL, etc.), security (authentication), and support for server-side rendering (SSR). Introducing BFFs allows FE teams to avoid pushing data fetching, denormalization, and aggregation logic into the FE apps, which reduces the risk of spaghetti code in the frontend, network usage for code and data, JavaScript bundle sizes, and compute resources used in the browser.
The BFF pattern is not without challenges, and Decathlon engineers devised strategies to ensure the new layer doesn’t negatively affect the overall quality of the platform. Arguably, the biggest risk comes from BFFs either inconsistently duplicating business logic between themselves or implementing business logic that should be managed lower in the call stack. Decathlon calls for creating an architecture committee for the purpose of regularly discussing such concerns and using ADRs to capture any resulting architectural decisions (AD).
Fault Tolerance and Graceful Degradation (Source: Decathlon Digital Blog)
The second main area that needs attention is fault tolerance to ensure BFF services handle errors gracefully and avoid overwhelming downstream services in case of instability. The team promotes circuit breaker and bulkhead patterns to react to and isolate downstream service failures. In case of failures, either potentially stale, cached data, or no data is returned to the frontend application, offering ways to downgrade user experience gracefully.
The last part of the series discusses alternatives to BFF, including over-the-air deployments (OTA), HATEOAS with HAL, and server-driven UI (SDUI), with their respective pros and cons and the level of fit for different types of FE applications and organization sizes.
InfoQ interviewed Raphaël Tahar, a staff engineer at Decathlon, about the company’s experience using the BFF pattern.
InfoQ: Can you broadly summarize Decathlon’s experience with the BFF pattern? What was the most challenging element/aspect of rolling out BFFs across the organization?
Raphaël Tahar:
The hardest constraint was to build a standard considering the wide variety of functional and technical use cases spread across the entire organization (thousands of projects).
- Some are used by internal users, others by customers
- Some experiences are consumed on browsers, others on mobile or connected devices
- The technology combinations complexity is variable (the tech radar includes ~10 frameworks across 4+ languages)
- Differences in team topologies (staffing & hard skills)
BFFs are no silver bullet, so pragmatism was a must-have and allowed us to build accurate decision trees, but it was not an easy ride.
InfoQ: Many organizations adopt GraphQL for orchestration/aggregation. Can you explain why you omitted it as an alternative to BFFs?
Tahar:
For me, GraphQL is more of a 'querying language - protocol' rather than an architectural pattern per se. It comes as a helmet, topping existing services and easing the cherry-picking of relevant data. So, it's a great addition to the BFF pattern, but I wouldn't say those two concepts are competing.
The point of the BFF is for a Frontend team to own the API serving their application, while GraphQL is more about optimizing payloads, endpoints, and traffic roundtrips. So, BFF and GraphQL are related but not mutually exclusive.
On the other hand, GraphQL Federation might be a serious alternative to BFFs, but implementing such architecture is not trivial, especially in large-scale organizations.
InfoQ: Micro Frontend Architecture (MFA) is another trending idea in the industry. Is Decathlon looking into adopting it?
Tahar:
Decathlon has been using build and runtime MFAs for years. For instance, Web Components are used to benefit from the Web Standards' purity and stability, but some limitations prevented global adoption. So, other technologies are used to bridge that gap (e.g., single-spa-based frameworks).