Frontend Engineering in Microservice Environments: Patterns for BFF, Partial Failures, and Distributed State
Implement a BFF that aggregates microservice calls and uses Promise.allSettled to return partial data, then build UI components that render independently based on ServiceResult status.
Set up a BFF layer that aggregates calls from User, Order, and Inventory services, use Promise.allSettled to return partial data, and update UI components to render based on ServiceResult status, adding error boundaries per service and defining timeout budgets.
Summary
Frontend engineers in microservice environments face four core problems: each service has its own contract, partial failures can occur, data may be stale, and assembling a page requires multiple round‑trips. A Backend‑for‑Frontend (BFF) layer solves these by sitting between the browser and the microservices, aggregating calls into a single endpoint, and exposing a frontend‑optimized contract. The BFF example shows a GET /api/order‑summary/:orderId endpoint that uses Promise.allSettled to fetch order, customer, and shipment data, returning partial results and an errors array instead of failing fast. On the UI side, the article introduces a ServiceResult<T> type that tracks loading, loaded, and error states, allowing components to render critical sections (like order details) while degrading non‑critical sections (recommendations, reviews) gracefully. Additional patterns include managing distributed state across services, defining timeout budgets for page assembly, and wrapping each service call in an error boundary. The article also advises when a BFF is worthwhile—three or more services per page, multiple clients needing different data shapes, or when backend teams cannot provide frontend‑optimized endpoints. Finally, it encourages close collaboration with backend teams to agree on contracts and to push back when necessary.
Key changes
- BFF aggregates multiple microservice calls into a single endpoint, reducing round‑trips from 3+ to 1
- BFF uses Promise.allSettled to return partial data and an errors array, avoiding fail‑fast behavior
- UI components use a ServiceResult<T> interface to track loading, loaded, and error states, enabling independent rendering of critical and non‑critical sections
- Error boundaries are applied per service to isolate failures and prevent a single service crash from breaking the entire page
- Timeout budgets are defined for page assembly to ensure the UI remains responsive even if some services are slow
- Distributed state management patterns are introduced to keep UI state consistent across services
- The article outlines criteria for when to implement a BFF, such as aggregating data from three or more services per page or serving multiple clients with different data shapes
- Collaboration guidelines with backend teams are provided to agree on API contracts and push back on problematic designs