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 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 germany telegram data 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.
A practical example of this approach would be a system with multiple devices, such as mobile and web applications, that have different protocols and technical requirements. At the same time, these devices may serve different roles, such as administrators or end users, each with unique flows. In this case, proxies can handle the technical diversity between devices, while orchestrators handle specific flows based on the user role.
In summary, Proxy + Orchestrator is a versatile and efficient solution for complex systems, as it allows technical and business variations to be addressed in a modular and scalable way.
4. API Gateways
API Gateways are a practical solution when you have third-party tools that can handle both protocol variations and workflows between different frontends. Instead of developing a custom BFF, you can leverage pre-built frameworks that simplify integration and allow you to manage the diversity of access in a centralized manner.
These tools are responsible for receiving requests from various frontends, adapting them as needed, and directing them to the appropriate services on the backend. API Gateways are especially useful for teams that prefer to delegate the complexity of access management, protocols, and authentication to tried-and-true external solutions.
A common example is the use of tools like Kong , AWS API Gateway , and API Platform , which act as a single entry point for requests from web, mobile, or even third-party systems. These gateways can unify different access methods, such as REST or GraphQL, and enforce consistent authentication and authorization policies.
In short, API Gateways are an efficient option for teams looking to simplify access and workflow management, relying on external tools that offer flexibility and robustness without the need to develop solutions from scratch.
5. Event Mediators
Event Mediators are ideal for Event -Driven Architectures , where the system logic is organized around mediating events between backend services and frontends. These mediators function as endpoints that distribute, transform, and process events according to the specific needs of each frontend or flow.
This approach splits the codebase, allowing for better event handling and greater system stability. Each mediator can focus on the specifics of a frontend or group of frontends, handling events in isolation and reducing the complexity of shared logic.