Backend for Frontend (BFF)

Cómo crear backends especializados por tipo de cliente para optimizar la experiencia de cada plataforma sin acoplar los servicios internos.

Qué problema resuelve

En una arquitectura de microservicios con un API Gateway único, todos los clientes (web, mobile, IoT, smart TV) consumen la misma API. Pero cada cliente tiene necesidades muy diferentes:

Mobile: Necesita respuestas compactas (ancho de banda limitado), datos agregados en pocas llamadas
Web SPA: Puede manejar más datos, necesita paginación y filtros avanzados
IoT: Solo necesita un subconjunto mínimo de datos con protocolos ligeros

Problema con un solo API Gateway:
  Mobile App ──► API Gateway ──► Microservicios
  Web App    ──► (misma API)
  IoT Device ──► (misma API)
  
  La API devuelve TODOS los campos para TODOS los clientes
  Mobile recibe datos que no necesita → desperdicio de ancho de banda
  Web no puede pedir datos extra sin afectar a mobile
  Cada cambio en la API afecta a todos los clientes

El resultado es una API “one-size-fits-all” que no satisface bien a ningún cliente, o una API llena de parámetros condicionales (?platform=mobile&fields=name,price) que se vuelve difícil de mantener.

Cómo funciona

El patrón BFF propone crear un backend dedicado para cada tipo de cliente. Cada BFF es un servicio ligero que actúa como intermediario entre su cliente específico y los microservicios internos.

Con BFF:
  Mobile App ──► BFF Mobile  ──┐
  Web App    ──► BFF Web     ──┤──► Microservicios
  IoT Device ──► BFF IoT     ──┘
  
  Cada BFF adapta las respuestas a su cliente
  Cada equipo de frontend controla su BFF
  Los microservicios no cambian

Responsabilidades del BFF

Responsabilidad	Descripción	Ejemplo
Agregación	Combinar datos de múltiples servicios	Dashboard mobile con 3 servicios en 1 llamada
Transformación	Adaptar formato y estructura de datos	Reducir campos para mobile, expandir para web
Orquestación	Coordinar llamadas a servicios en orden	Login → perfil → preferencias en secuencia
Caché específico	Cachear según patrones del cliente	Mobile cachea catálogo 10 min, web 2 min
Autenticación	Manejar auth específica del cliente	OAuth para web, API key para IoT

Ejemplo: endpoint de producto

Microservicio Product Service devuelve:
{
  "id": "P001",
  "name": "Laptop Pro",
  "description": "Laptop de alto rendimiento...",
  "specs": { "cpu": "i9", "ram": "32GB", "storage": "1TB" },
  "images": ["url1.jpg", "url2.jpg", "url3.jpg", "url4.jpg"],
  "reviews": [...50 reviews...],
  "relatedProducts": [...10 productos...],
  "inventory": { "warehouse1": 50, "warehouse2": 30 },
  "pricing": { "base": 1500, "discount": 10, "tax": 15 }
}

BFF Mobile devuelve:
{
  "id": "P001",
  "name": "Laptop Pro",
  "image": "url1_thumb.jpg",
  "price": "$1,350",
  "rating": 4.5
}

BFF Web devuelve:
{
  "id": "P001",
  "name": "Laptop Pro",
  "description": "Laptop de alto rendimiento...",
  "specs": { "cpu": "i9", "ram": "32GB", "storage": "1TB" },
  "images": ["url1.jpg", "url2.jpg", "url3.jpg", "url4.jpg"],
  "reviewSummary": { "average": 4.5, "count": 50 },
  "price": { "original": 1500, "final": 1350, "discount": "10%" },
  "relatedProducts": [...3 productos...]
}

Propiedad del BFF

Un principio clave del patrón es que el equipo de frontend es dueño de su BFF. Esto permite:

El equipo mobile decide qué datos necesita y cómo los estructura
Los cambios en la UI no requieren coordinar con otros equipos
Cada BFF evoluciona al ritmo de su cliente

Ventajas

Optimización por cliente: Cada plataforma recibe exactamente los datos que necesita
Autonomía de equipos: El equipo de frontend controla su backend sin depender de otros
Evolución independiente: Cambios en la API mobile no afectan a web ni a IoT
Rendimiento: Menos datos transferidos, menos llamadas desde el cliente
Simplicidad del cliente: El frontend consume una API diseñada específicamente para él
Seguridad granular: Cada BFF puede implementar políticas de seguridad específicas

Trade-offs / Desventajas

Duplicación de código: Lógica similar puede repetirse entre BFFs (mitigable con librerías compartidas)
Más servicios que mantener: Cada BFF es un servicio adicional que necesita despliegue y monitoreo
Consistencia: Diferentes BFFs pueden devolver datos inconsistentes si no se coordinan
Complejidad organizacional: Requiere equipos con capacidad full-stack (frontend + su BFF)
Latencia: Un salto adicional entre el cliente y los microservicios
Riesgo de BFF monolítico: Si el BFF crece demasiado, se convierte en un mini-monolito

Cuándo usar

Múltiples tipos de cliente con necesidades de datos muy diferentes
Equipos de frontend que necesitan autonomía para evolucionar su API
Aplicaciones mobile donde el ancho de banda y la cantidad de llamadas importan
Cuando un API Gateway único se vuelve demasiado complejo con lógica condicional por cliente
Organizaciones con equipos dedicados por plataforma (equipo mobile, equipo web)

Cuándo evitar

Un solo tipo de cliente (solo web, o solo mobile)
Clientes con necesidades de datos muy similares
Equipos pequeños donde mantener múltiples BFFs no se justifica
Cuando un API Gateway con transformaciones simples es suficiente
Prototipos o MVPs donde la velocidad de desarrollo es prioridad

Tecnologías e implementaciones comunes

Categoría	Opciones
Frameworks	Express/Fastify (Node.js), Spring Boot (Java), ASP.NET Core (.NET)
GraphQL como BFF	Apollo Server, Hasura, Strawberry (Python)
API Gateway + BFF	Kong + servicios BFF, AWS API Gateway + Lambda
Comunicación interna	gRPC entre BFF y microservicios, REST, mensajería

Relación con otros patrones

API Gateway: El BFF es una especialización del API Gateway por tipo de cliente
Microservicios: Los BFFs consumen microservicios internos y los adaptan
Anti-Corruption Layer: El BFF puede actuar como ACL entre el frontend y servicios legacy
Circuit Breaker: Cada BFF debe implementar circuit breaking hacia los servicios que consume

Próximos pasos

El BFF te da control granular sobre la experiencia de cada cliente. Para entender cómo descomponer los servicios que el BFF consume, explora el patrón Microservicios. Para proteger la comunicación entre el BFF y servicios externos, revisa el Anti-Corruption Layer.