An Aries client recently decided to tackle BFF (Backend for Frontend) layers, how they should be implemented, and which best practices should be followed in a composable implementation. Our CTO, Tim Steele, provided an impressive workshop diving into the details, edge cases, and best practices tying it all directly to this specific project. While it’s impossible to capture the immense value this workshop provided in a blog post, I’d like to discuss some of the highlights.
The concept of a Backend for Frontend has grown in popularity, becoming a pivotal architectural pattern in modern ecommerce development. Having this added compute layer helps serve the unique requirements of different clients – web, mobile, voice, and more. Reading the basic definition of a BFF makes it seem straightforward, but there are many nuances of implementing this pattern effectively that can be learned the hard way, through experience, or shared by professionals who have been down this road many times before.
There are four distinct approaches to implementing a middle layer between the client and API services:
1. One-for-One BFF: This approach involves creating separate BFF layers for each client type (e.g., web, mobile, kiosk). While it minimizes dependency issues, it sacrifices shared development and reusability.
2. Unified BFF: A single BFF layer serving all client types promotes shared development and reusability. However, this can quickly grow into a monolithic structure, concentrating all logic and schema in one place.
3. Federated/Stitched BFF: Here, independent BFFs for each client feed into a unified layer. This model supports independent development while allowing shared reusability and orchestration.
4. Third-Party BFF Platforms: Deploying functions into a third-party platform for orchestration and connection offers independence and reusability but introduces additional vendor integrations.
Backend for Frontend Implementation Tips
Regardless of the approach, there are a few things that should be considered when designing a BFF and developing the requirements.
One of the primary advantages of a BFF is its ability to combine multiple API calls into one. This capability not only enhances performance by reducing the number of calls but also allows for effective caching strategies. However, it’s crucial to consider the variability of data freshness. For example, product descriptions might tolerate longer cache times, but inventory data is highly dynamic and requires a shorter cache, no cache, or separate handling. A BFF can be built with any API protocol. REST is still the leader, but GraphQL brings some unique benefits such as schema stitching. The ability to merge multiple GraphQL endpoints into a single unified API with object-level caching makes it a strong fit for a BFF.
Once a BFF layer is in place, it becomes very tempting to add all requirements into this layer. It’s an easy place to add any weird requirements, integrations, or one-off implementations. This can quickly become a mess. Remember that a BFF layer is designed to support the client’s needs and should be considered part of the UI layer. It’s not appropriate to add integrations, asynchronous functionality, CHRON jobs, or business logic inside of the BFF.
Not every project requires a BFF layer. Consider the project requirements and if one is truly needed. You should be considering a BFF if your website, mobile app, or other clients have extensive server-side needs, you are adopting a strangler pattern migration, or you need to control the API schema being called. Mobile apps get the added benefit of being able to handle patches, changes, and updates without needing to resubmit the app for approval. You should also determine monitoring requirements where a BFF layer can provide additional insight into the quantity, speed, and error volume of third-party services.
Performance and scalability are major factors when determining if a BFF should be leveraged. Depending on implementation, the BFF layer can be a huge bonus or a major pitfall. This layer is now a critical component, and any downtime or degradation at this layer can impact the customer experience. In practice, we have noticed that bottlenecks more often occur in upstream services rather than the BFF itself. In this case, having an intelligent cache can decrease demand on those services and compensate for outages or response time issues. As mentioned, the caching strategy will change depending on the volatility of the data. Some data can handle traditional caching while others require more innovative solutions like snapshotting and reconciliation.
Conclusion
From a development perspective, backend for frontend layers offer flexibility in data manipulation and formatting, easing frontend development. They also support better debugging and local development practices, providing a structured approach to managing data flow and response formats.
That doesn’t mean a BFF is a silver bullet for every composable architecture. There is no one-size-fits-all approach. The decision hinges on project needs, team structure, and scalability requirements. Understanding the trade-offs and benefits can determine a successful implementation with a robust, responsive, and efficient architecture.
If you are currently planning or debating your ecommerce architecture, I would highly recommend reaching out to our team. We can provide crucial guidance and workshops, an evaluation, and development help to ensure you have a successful project.