BFFs can be classified based on the type of component dedicated to each scenario or frontend (Web, APP, etc.):
1. Proxies
Proxies are a variant of Backends for Frontends (BFF) designed to handle differences in protocols, authorizations, or encryption between different types of frontends. Their main strength is the ability to handle these variations without modifying the underlying workflows, making them an ideal choice when frontends share a common business logic.
In this architecture, each frontend team can have its own loadrunner protocol list proxy, tailored specifically to the needs of its frontend. This proxy acts as an intermediate layer between the frontend and the general system API, adjusting requests and responses to ensure compatibility and efficiency.
Proxies are characterized by being lightweight, focusing exclusively on adapting data and protocols without adding complex logic or additional responsibilities.
Imagine a system with mobile and web applications. Although both interact with the same core services, they might need different data formats or handle protocols like REST on the web and GraphQL in an APP. Here, a specific proxy for each frontend can take care of these adaptations without modifying the main backend.
In short, proxies are an efficient and flexible solution to manage technical differences between frontends while maintaining simplicity in the design of the overall architecture.
2. Orchestrators
Orchestrators are a variant of Backends for Frontends (BFF) that are used when frontends have completely different workflows. Instead of simply adapting requests and responses as proxies do, orchestrators take responsibility for coordinating multiple underlying services to deliver a unified experience tailored to the specific needs of each frontend.
Each frontend has its own dedicated backend, which contains the specific logic required for its workflow. This allows for a clear separation between different roles or types of users, optimizing interaction with the system.
Orchestrators excel at managing the complexity of systems where frontends perform tasks that don't share much in common.
In an e-commerce store, consumers and administrators have completely different workflows. Consumers access features such as product search, ordering, and payment. Administrators manage inventory, monitor statistics, and process returns.
To manage these differences, a dedicated orchestrator for consumers can coordinate services such as products, shopping cart, and payment gateway, while another orchestrator for administrators focuses on inventory and reporting services.
In short, orchestrators are ideal for systems where the diversity of workflows requires a specialized backend to ensure efficiency and clarity in handling the operations of each frontend.
3. Proxy + Orchestrator
The Proxy + Orchestrator approach is ideal when frontends vary both in the protocol they use and the workflows they require. This model combines the capabilities of proxies to manage technical aspects, such as protocols and authorizations, with those of orchestrators to handle the logic specific to each frontend's flows.
On the one hand, proxies are responsible for adapting requests based on the device or type of frontend, managing differences such as REST, GraphQL or specific authentication. On the other hand, orchestrators coordinate the services needed to execute the specific flows of each frontend, providing an optimized and consistent experience.