Un Backend para Frontend (BFF) es un servicio backend dedicado a un frontend específico. En lugar de que web, iOS, Android o integraciones externas consuman el mismo backend genérico, cada cliente usa una capa del lado del servidor que agrega, filtra y reformula datos desde microservicios para devolver exactamente la carga útil que esa interfaz necesita.
Sam Newman nombró y popularizó el patrón en 2015 a partir del trabajo realizado en SoundCloud. Hoy sigue siendo una opción habitual para equipos que ejecutan microservicios detrás de múltiples aplicaciones cliente, y Microsoft lo documenta como un patrón de arquitectura en la nube.
El problema que resuelve un BFF
Suponga que empieza con una aplicación web y un backend REST. Todo funciona bien hasta que aparecen más clientes:
- una app móvil;
- una integración con socios;
- un widget para reloj inteligente;
- una interfaz interna de administración.
Si todos consumen el mismo backend, ese backend termina intentando satisfacer necesidades incompatibles.
1. Over-fetching y under-fetching
Un endpoint genérico devuelve una estructura fija.
Ejemplo:
GET /customers/123
Puede devolver:
{
"id": "123",
"name": "Ana",
"email": "ana@example.com",
"orders": [...],
"recommendations": [...],
"accountSettings": {...},
"loyaltyStatus": "gold"
}
Para un dashboard web, esa respuesta puede ser útil. Para una pantalla móvil que solo necesita name, loyaltyStatus y el número de notificaciones, es demasiado pesada.
El resultado suele ser uno de estos dos problemas:
- Over-fetching: el cliente descarga datos que no usa.
- Under-fetching: el cliente hace varias llamadas adicionales para completar la pantalla.
2. Clientes demasiado “charlatanes”
Sin una API adaptada a la pantalla, el cliente termina orquestando llamadas:
GET /profile/me
GET /notifications/count
GET /feed
GET /recommendations
Luego combina todo en el dispositivo.
Eso aumenta:
- latencia;
- consumo de batería;
- lógica duplicada en clientes;
- dificultad para probar y versionar cambios.
La tensión también es organizacional: cada equipo de frontend pide cambios al mismo backend compartido. Cada cambio debe validarse contra todos los clientes, y el backend se convierte en cuello de botella.
Cómo funciona el patrón BFF
El patrón BFF introduce una capa delgada entre un frontend y los servicios descendentes. Cada experiencia de cliente obtiene su propio backend.
[ Aplicación web ] ---> [ BFF web ] ---\
[ Aplicación iOS ] ---> [ BFF iOS ] -----> [ Microservicios ]
[ Aplicación Android ] ---> [ BFF Android ] ---/
Cada BFF suele encargarse de tres tareas.
1. Agregación
El BFF llama a varios servicios y devuelve una sola respuesta al cliente.
Ejemplo:
GET /mobile/home
Internamente, el BFF puede llamar en paralelo a:
GET /users/me
GET /notifications/count
GET /feed?limit=10
Y devolver una respuesta optimizada:
{
"user": {
"name": "Ana"
},
"notifications": 4,
"feed": [
{
"id": "post_1",
"title": "Nuevo lanzamiento"
}
]
}
Esto es agregación de API aplicada a una experiencia concreta. Si quiere profundizar en la idea general, consulte el patrón agregador de API.
2. Remodelación
El BFF adapta la forma de los datos al cliente:
- elimina campos innecesarios;
- renombra propiedades;
- aplana estructuras anidadas;
- formatea valores;
- devuelve payloads ligeros para móvil y más completos para escritorio.
Ejemplo de salida móvil:
{
"displayName": "Ana",
"badge": "gold"
}
Ejemplo de salida web:
{
"customer": {
"id": "123",
"name": "Ana",
"email": "ana@example.com",
"loyalty": {
"status": "gold",
"points": 1280
},
"recentOrders": [...]
}
}
3. Traducción
El BFF también puede adaptar decisiones específicas del cliente:
- estrategia de paginación;
- caché;
- protocolo;
- formato de fechas;
- compatibilidad con versiones anteriores de la app;
- adaptación entre REST, gRPC u otros servicios internos.
Los microservicios descendentes siguen siendo agnósticos al frontend. Exponen capacidades reutilizables. El BFF concentra la adaptación específica del cliente.
Si necesita contexto sobre la capa subyacente, vea estas guías sobre microservicios versus APIs y el paso de una aplicación monolítica a microservicios.
Un BFF por experiencia de cliente
La regla práctica de Newman es:
Una experiencia, un BFF.
Si web, iOS y Android tienen experiencias claramente distintas, cree un BFF para cada una.
web -> bff-web
iOS -> bff-ios
Android -> bff-android
El objetivo es evitar que un BFF acumule condicionales como estos:
if (client === "mobile") {
return mobilePayload;
}
if (client === "web") {
return webPayload;
}
Cuando eso ocurre, el BFF empieza a convertirse otra vez en un backend genérico.
Hay una excepción razonable: si el mismo equipo posee iOS y Android, y ambas apps tienen casi la misma experiencia, puede compartir un único BFF móvil.
iOS -> bff-mobile
Android -> bff-mobile
La decisión debe basarse en dos criterios:
- similitud real de las necesidades de datos;
- propiedad por el mismo equipo.
La propiedad pertenece al equipo de frontend
Un BFF no debería ser una capa construida por un equipo de plataforma y entregada a los equipos de producto. El equipo que posee el frontend debería poseer también su BFF.
Eso permite que el equipo:
- defina endpoints según las pantallas que construye;
- despliegue cambios de UI y backend juntos;
- elija lenguaje y runtime;
- priorice su propio backlog;
- evite tickets bloqueados en un equipo de backend central.
Ejemplo de flujo:
- El equipo móvil diseña una nueva pantalla de inicio.
- Define el contrato
GET /mobile/home. - Implementa el BFF para agregar perfil, notificaciones y feed.
- Lanza app y BFF en la misma iteración.
Esta autonomía encaja con la idea de conectividad dirigida por API, donde la capa de experiencia se adapta a cada consumidor.
BFF vs. API Gateway
Un BFF y un API Gateway pueden parecer similares en un diagrama, pero cumplen funciones distintas.
Un API gateway gestiona preocupaciones transversales:
- autenticación;
- rate limiting;
- enrutamiento;
- terminación TLS;
- logging;
- observabilidad;
- políticas comunes.
Es una capa de entrada general, normalmente propiedad de plataforma o infraestructura.
Un BFF, en cambio, es específico del cliente. Su propósito es adaptar datos y comportamiento a una experiencia concreta.
Una arquitectura común combina ambos:
[ Cliente web ] \
[ Cliente móvil ] ---> [ API Gateway ] ---> [ BFF específico ] ---> [ Microservicios ]
[ Socio externo ] /
Use el API Gateway para lo que es igual en todos los clientes. Use un BFF para lo que cambia por cliente.
Para ampliar el contexto, estas comparaciones son útiles:
Cuándo usar un BFF
Use un BFF cuando se cumplan varias de estas condiciones.
Tiene clientes realmente distintos
Por ejemplo:
- web necesita dashboards ricos;
- móvil necesita payloads pequeños;
- socios externos necesitan contratos estables;
- dispositivos limitados necesitan respuestas mínimas.
Cuanto más divergen las experiencias, más valor aporta un BFF.
El backend compartido se volvió un cuello de botella
Señales típicas:
- cada cambio de frontend requiere coordinación con varios equipos;
- el backend tiene endpoints llenos de parámetros opcionales;
- aparecen condicionales por tipo de cliente;
- los equipos no pueden desplegar al ritmo que necesitan.
Necesita payloads optimizados por cliente
Ejemplo:
GET /web/customer-dashboard/123
GET /mobile/customer-summary/123
Ambos pueden depender de los mismos microservicios, pero devuelven respuestas distintas.
Un runtime encaja mejor con un cliente
Un equipo puede escribir su BFF en Node.js, Go, Java, .NET u otro entorno, siempre que encaje con sus necesidades y capacidades operativas.
Cuándo no usar un BFF
El patrón añade coste. No lo use por defecto.
Solo tiene un cliente
Si solo existe una interfaz, un BFF suele ser un salto extra. Construya un backend normal.
Sus clientes consumen lo mismo
Si web y móvil necesitan casi los mismos datos con la misma estructura, separar BFFs puede duplicar trabajo sin aportar valor.
GraphQL ya resuelve el problema
GraphQL permite que cada cliente pida exactamente los campos que necesita desde un único endpoint.
query {
customer(id: "123") {
name
loyaltyStatus
}
}
Eso reduce over-fetching y under-fetching. Si ya tiene una capa GraphQL con resolvedores adecuados para cada frontend, un BFF adicional puede no aportar mucho.
Antes de añadir otra capa, revise qué es GraphQL.
Una pasarela más microservicios es suficiente
Para sistemas simples, un API Gateway delante de microservicios bien diseñados puede ser suficiente.
Desventajas del patrón BFF
Incluso cuando encaja, el BFF tiene costes reales.
Duplicación de código
Tres BFFs pueden terminar implementando la misma lógica:
- validación de autenticación;
- formateo de fechas;
- manejo de errores;
- transformación de modelos.
Mitigación:
- mueva lógica compartida a librerías;
- mantenga autenticación, rate limiting y logging común en el API Gateway;
- reserve el BFF para adaptación específica del cliente.
Más servicios que operar
Cada BFF requiere:
- despliegue;
- pipeline CI/CD;
- monitoreo;
- alertas;
- gestión de secretos;
- parches de seguridad;
- ownership claro.
No cree BFFs si no puede operarlos.
Un salto de red adicional
El cliente ya no llama directamente a los servicios. Llama al BFF.
Eso puede añadir latencia, aunque muchas veces la reduce porque reemplaza varias llamadas del cliente por una sola llamada al BFF, que luego consulta servicios internos en paralelo.
Mida ambos escenarios:
cliente -> servicio A
cliente -> servicio B
cliente -> servicio C
frente a:
cliente -> BFF -> servicios A, B, C en paralelo
Riesgo de inflación
Un BFF debe mantenerse delgado. No debería absorber lógica de negocio que pertenece a microservicios.
Evite que el BFF se convierta en:
- un monolito por accidente;
- una capa de reglas de negocio;
- un backend compartido para muchos clientes incompatibles.
Mantener los contratos BFF sincronizados con Apidog
La parte difícil de operar BFFs son los contratos. Cada BFF expone una API orientada al cliente y, al mismo tiempo, depende de APIs internas de microservicios. Cuando esos contratos cambian sin coordinación, aparecen errores.
Apidog encaja en este flujo como plataforma de diseño, pruebas, simulación y documentación de APIs. No construye ni ejecuta el BFF, pero ayuda a mantener claros sus contratos.
1. Diseñe el contrato primero
Defina endpoints, parámetros y esquemas antes de implementar.
Ejemplo de contrato para una pantalla móvil:
GET /mobile/home
Respuesta esperada:
{
"user": {
"id": "123",
"displayName": "Ana"
},
"notifications": {
"unread": 4
},
"feed": [
{
"id": "post_1",
"title": "Nuevo lanzamiento",
"publishedAt": "2026-07-02T10:00:00Z"
}
]
}
Este enfoque aplica el diseño contract-first a la capa BFF y mantiene explícito el contrato de API.
2. Simule el BFF antes de implementarlo
El frontend puede empezar a integrarse contra un mock del contrato mientras el BFF real todavía no existe.
Flujo práctico:
- El equipo acuerda el contrato.
- Se publica un mock.
- El frontend consume el mock.
- El backend implementa el BFF.
- Las pruebas validan que la implementación cumple el contrato.
3. Pruebe el contrato en CI
Use pruebas automatizadas para comprobar que el BFF devuelve la forma esperada.
Ejemplos de validaciones:
- el campo
notifications.unreadexiste y es numérico; -
feedes un array; - cada elemento de
feedcontieneid,titleypublishedAt; - no se devuelven campos internos innecesarios.
Esto ayuda a detectar cambios descendentes que rompen una respuesta del BFF antes de llegar a producción.
4. Documente para frontend y backend
La documentación interactiva generada desde el contrato permite que:
- el equipo frontend sepa cómo consumir el BFF;
- el equipo backend entienda qué datos dependen de sus microservicios;
- QA pueda probar endpoints sin leer código;
- nuevos miembros del equipo entiendan la API rápidamente.
Tratar cada BFF como un producto, con contrato estable y documentación clara, hace que el patrón sea más sostenible.
Preguntas frecuentes
¿Un BFF es un microservicio?
Es un servicio del lado del servidor y puede desplegarse como microservicio, pero su función es distinta.
Un microservicio suele poseer una capacidad de negocio y ser agnóstico al cliente. Un BFF posee una experiencia de cliente y existe para agregar, filtrar y remodelar datos para esa experiencia.
¿Cuántos BFFs debería tener?
Como regla inicial: uno por experiencia de cliente distinta.
Ejemplo:
web -> bff-web
iOS -> bff-ios
Android -> bff-android
Combine dos solo si tienen necesidades casi idénticas y el mismo equipo las mantiene.
¿GraphQL reemplaza el patrón BFF?
Puede reemplazar parte del patrón, especialmente la conformación de payloads. GraphQL resuelve bien over-fetching y under-fetching.
Un BFF sigue siendo útil si necesita:
- orquestación específica por cliente;
- traducción de protocolos;
- lógica de compatibilidad por versión de app;
- runtime separado por equipo;
- integración con servicios internos heterogéneos.
¿Puedo usar BFF y API Gateway juntos?
Sí. Es una combinación común.
Cliente -> API Gateway -> BFF -> Microservicios
El API Gateway gestiona preocupaciones comunes. El BFF gestiona adaptación específica del cliente.
¿Quién debería ser propietario del BFF?
El equipo de frontend que posee el cliente.
Esa propiedad permite desplegar cambios de UI y endpoints juntos, sin depender de una cola centralizada de backend.
¿Un BFF añade latencia?
Añade un salto de red. Sin embargo, puede reducir la latencia total si reemplaza varias llamadas del cliente por una sola llamada al BFF y el BFF consulta servicios internos en paralelo.
La respuesta correcta depende de su carga de trabajo: mídalo.
Top comments (0)