# API integration ‒ Backend for frontend The [Backends for Frontends (BFF) pattern](https://aws.amazon.com/blogs/mobile/backends-for-frontends-pattern/) is typically used in microservices environments. In the context of micro-frontends, a BFF is a server-side service that belongs to a micro-frontend. Not all micro-frontends need to have a BFF. However, if you're using a BFF, it must run inside the same bounded context and not be shared across other bounded contexts. Unlike a traditional service, a BFF doesn't not follow a domain model. Instead, it's an API layer for the micro-frontend to preprocess data before it reaches the client. Areas where this is useful include the following: + Authorization toward private APIs + Aggregation of data from different sources + Transformation of data to reduce network load and to ease the consumption of data by the client As such, a BFF is owned by the micro-frontend, not by the domain service tier. BFFs can be deployed by using the following: + AWS AppSync GraphQL APIs + A set of AWS Lambda functions + As a container running on Amazon ECS, Amazon EKS, or AWS AppRunner The following diagram shows that without the BFF pattern, micro-frontends must connect to individual microservice API endpoints to fetch and aggregate data. ![Dashboard app that first fetches transactions and then fetches prices from decoupled microservices.](http://docs.aws.amazon.com/prescriptive-guidance/latest/micro-frontends-aws/images/mfe-architectures-without-bff.png) Instead, with the BFF pattern in the following diagram, micro-frontends can communicate with their own backend and fetch aggregated data. ![The transactions view fetches aggregated data, including price information, from the BFF.](http://docs.aws.amazon.com/prescriptive-guidance/latest/micro-frontends-aws/images/mfe-architectures-with-bff.png) Teams can develop BFFs for different channels such as mobile, web, or specific views, with requirements to optimize backend interactions by reducing chattiness.