“BFF vs. Pasarela de API” es uno de los enfrentamientos que más confusión generan en la arquitectura de microservicios. Los dos patrones parecen similares en un diagrama: ambos se sitúan frente a tus servicios, reciben solicitudes del cliente y las entregan a los backends. Por eso muchos equipos los tratan como alternativas, eligen uno y terminan asignándole responsabilidades equivocadas.
No son competidores. Un Backend para Frontend (BFF) y una pasarela de API resuelven problemas diferentes, suelen ser propiedad de equipos diferentes y, en sistemas reales, normalmente funcionan juntos. El BFF se sitúa detrás o junto a la pasarela, no en su lugar.
Esta guía marca el límite práctico: qué hace cada patrón, cuándo usar uno o ambos, y qué errores evitar. La constante en todos los casos es el contrato de API: si una solicitud pasa por una pasarela, por un BFF o por ambos, cada capa expone una API que debes diseñar, probar, simular y documentar.
¿Qué es una Pasarela de API?
Una pasarela de API es un punto de entrada centralizado entre los clientes y tus servicios de backend. Todas las solicitudes pasan por ella antes de llegar a los servicios ascendentes.
Su trabajo principal es aplicar preocupaciones transversales:
- Enrutamiento: asignar una ruta entrante al servicio correcto.
- Autenticación y autorización: validar tokens y rechazar solicitudes no autorizadas.
- Limitación de velocidad y estrangulamiento: proteger los backends de sobrecarga o abuso.
- Observabilidad: registrar solicitudes, emitir métricas y propagar trazas.
- Terminación TLS, caché y transformaciones básicas: centralizar tareas de infraestructura.
La pasarela es de propósito general y normalmente pertenece al equipo de plataforma o infraestructura. No debería importar si el cliente es una app móvil, una SPA web o una integración de terceros: aplica políticas uniformes.
Ejemplo de responsabilidades que sí encajan en una pasarela:
gateway:
routes:
- path: /api/products/*
upstream: product-service
- path: /api/orders/*
upstream: order-service
policies:
auth: required
rate_limit:
requests_per_minute: 600
observability:
logs: enabled
tracing: enabled
Esto convierte a la pasarela en el lugar correcto para reglas organizacionales. Si todas las APIs deben validar tokens de la misma forma o usar el mismo límite de velocidad, la pasarela lo aplica sin duplicar lógica en cada servicio. Para ver cómo se diferencia de una plataforma más amplia, consulta Gestión de API vs. Pasarela de API.
¿Qué es un Backend para Frontend (BFF)?
Un Backend para Frontend, introducido por Sam Newman, cambia el enfoque: en lugar de crear un backend genérico para todos los clientes, construyes un backend por experiencia de usuario.
- La aplicación web puede tener un BFF web.
- La aplicación móvil puede tener un BFF móvil.
- Clientes similares, como iOS y Android mantenidos por el mismo equipo, pueden compartir uno.
La regla práctica es: una experiencia, un BFF.
El BFF está estrechamente acoplado a un frontend específico y normalmente lo mantiene el mismo equipo que desarrolla esa interfaz. Esto permite evolucionar la UI y su backend juntos, sin depender de un backend compartido que se convierta en cuello de botella, como ocurre a veces con un monolito.
Un BFF da forma a los datos para un cliente concreto:
- Agregación: una pantalla móvil necesita datos de cinco microservicios; el BFF llama a esos servicios y devuelve una única respuesta.
- Recorte de datos: el móvil solo necesita 3 campos de una entidad que tiene 40; el BFF elimina lo innecesario.
- Formato específico del cliente: escritorio puede necesitar una vista rica con varias páginas; móvil puede necesitar una respuesta más pequeña y paginada.
Ejemplo simplificado de un endpoint de BFF móvil:
// GET /mobile/product-summary/:id
app.get("/mobile/product-summary/:id", async (req, res) => {
const productId = req.params.id;
const [product, inventory, price] = await Promise.all([
productService.getProduct(productId),
inventoryService.getAvailability(productId),
pricingService.getPrice(productId),
]);
res.json({
id: product.id,
name: product.name,
image: product.thumbnailUrl,
available: inventory.available,
price: price.current,
});
});
El BFF es un tipo de agregador de API, pero con un objetivo específico: servir a una experiencia de usuario concreta, no actuar como una capa neutral para todos.
Dónde se Superponen el BFF y la Pasarela de API
La confusión existe porque ambos patrones pueden parecer similares:
- Ambos reciben solicitudes de clientes.
- Ambos pueden enrutar a backends.
- Ambos pueden llamar a varios servicios.
- Ambos pueden devolver una respuesta compuesta.
Pero la diferencia clave está en la intención y la propiedad:
- Una pasarela de API enruta y aplica políticas de forma genérica, para todos los clientes.
- Un BFF agrega y transforma datos de forma específica, para un frontend.
La regla práctica:
Si una responsabilidad es igual para todos los clientes, va en la pasarela.
Si cambia por frontend, va en el BFF.
Por ejemplo:
Autenticación común -> Pasarela de API
Limitación de velocidad -> Pasarela de API
Logs y métricas comunes -> Pasarela de API
Payload específico de móvil -> BFF móvil
Payload específico de web -> BFF web
Agregación para una pantalla -> BFF
Microsoft recomienda mantener las preocupaciones transversales fuera del BFF. Si pones autenticación, autorización, limitación de velocidad y monitorización en cada BFF, terminarás reconstruyendo una pasarela varias veces y con políticas inconsistentes.
BFF y Pasarela de API Trabajando Juntos
En microservicios reales, lo habitual no es elegir uno, sino usar ambos en capas:
Cliente
|
v
Pasarela de API
|
v
BFF específico del cliente
|
v
Microservicios
Flujo típico:
- El cliente móvil envía una solicitud con su token.
- La pasarela de API valida el token, aplica límites de velocidad, registra la solicitud y enruta al BFF móvil.
- El BFF móvil llama a servicios como productos, inventario y precios.
- El BFF agrega y recorta la respuesta para la pantalla móvil.
- La pasarela devuelve la respuesta al cliente.
Ejemplo de respuesta agregada por un BFF móvil:
{
"id": "prod_123",
"name": "Teclado mecánico",
"image": "https://cdn.example.com/prod_123.png",
"available": true,
"price": {
"amount": 79.99,
"currency": "EUR"
}
}
Cada capa conserva una responsabilidad clara:
- La pasarela aplica políticas uniformes.
- El BFF modela la respuesta para una experiencia.
- Los microservicios mantienen la lógica de dominio.
Esto también evita acoplar a los equipos equivocados. El equipo de frontend puede desplegar cambios en su BFF sin pedir cambios en la pasarela. El equipo de plataforma puede ajustar límites de velocidad sin redeplegar los BFFs.
Esta separación es similar a cómo una pasarela coexiste con otros componentes de infraestructura. Una pasarela no reemplaza a un equilibrador de carga (pasarela de API vs. equilibrador de carga) ni a una malla de servicios (malla de servicios vs. pasarela de API). Cada capa tiene una tarea distinta dentro de la ruta de solicitud. Es el mismo principio detrás de la conectividad dirigida por API: una capa, una responsabilidad.
Tabla de Decisiones: BFF vs. Pasarela de API
| Pregunta | Pasarela de API | BFF |
|---|---|---|
| ¿Quién lo posee? | Equipo de plataforma / infraestructura | Equipo de frontend que lo consume |
| ¿A quién sirve? | A todos los clientes de forma uniforme | A un frontend específico |
| Función principal | Autenticación, autorización, limitación de velocidad, enrutamiento, observabilidad | Agregación y modelado de datos específicos del cliente |
| ¿Cuántos ejecutas? | Normalmente una por borde | Uno por experiencia de usuario distinta |
| Acoplamiento | Bajo, agnóstico del cliente | Alto, específico del cliente por diseño |
| Cadencia de cambio | Estable, gobernada por plataforma | Rápida, alineada con el frontend |
| Qué le corresponde | Lo idéntico para todos los clientes | Lo único para un cliente |
Úsalo como una matriz de decisión:
¿La responsabilidad aplica igual a todos?
Sí -> Pasarela de API
No -> BFF
¿La respuesta depende de la pantalla o experiencia?
Sí -> BFF
¿Es una política de seguridad o plataforma?
Sí -> Pasarela de API
Cuando una solicitud necesita ambas cosas —por ejemplo, autenticación centralizada y payload específico para móvil— usa ambas capas.
Cuándo Usar Cuál
Usa una pasarela de API cuando
Tienes múltiples servicios y necesitas un punto central para:
- Autenticación y autorización.
- Limitación de velocidad.
- Enrutamiento.
- Observabilidad.
- Políticas comunes.
Si expones más de unos pocos servicios a clientes, normalmente necesitas una pasarela antes que un BFF.
Usa un BFF cuando
Diferentes clientes necesitan respuestas significativamente distintas del mismo backend.
Señales comunes:
- Un backend compartido se volvió difícil de mantener porque sirve a varios frontends en competencia.
- Estás agregando condicionales por cliente en una API general.
- Móvil y web tienen necesidades reales distintas de datos, latencia o payload.
- Una pantalla requiere combinar datos de varios servicios y no quieres que el cliente haga múltiples llamadas.
Ejemplo de mala señal en una API compartida:
if (clientType === "mobile") {
return compactProductView(product);
}
if (clientType === "desktop") {
return detailedProductView(product);
}
return defaultProductView(product);
Si este patrón crece, probablemente necesitas BFFs separados.
Omite el BFF cuando
No lo uses por defecto. Evítalo si:
- Solo tienes un cliente.
- Todos los clientes consumen datos similares.
- Una API compartida sirve bien a todos.
- Una capa GraphQL con resolutores por frontend ya permite a los clientes pedir exactamente los campos necesarios.
Un BFF añade otro salto de red, otro servicio que desplegar y posibles duplicaciones entre equipos. Si no hay divergencia real entre clientes, es sobreingeniería.
Usa ambos cuando
Ejecutas microservicios a escala y tienes:
- Políticas comunes en el borde.
- Varios frontends con necesidades diferentes.
- Equipos de frontend que necesitan evolucionar rápido.
- Contratos de API independientes por experiencia.
Este es el caso más común en sistemas maduros: pasarela en el borde, BFFs detrás.
Errores Comunes
Poner autenticación y limitación de velocidad en el BFF
Es el error más frecuente. Estas son preocupaciones transversales y pertenecen a la pasarela.
Si cada BFF implementa sus propias reglas, aparecerá deriva:
BFF móvil -> límite de 100 req/min
BFF web -> límite de 500 req/min
BFF socios -> sin límite claro
El resultado es una postura de seguridad inconsistente.
Convertir el BFF en un segundo monolito
Un BFF debe ser pequeño y centrado en una experiencia. No lo uses para concentrar lógica de negocio compartida.
Incorrecto:
BFF móvil
- Agregación para pantallas móviles
- Reglas de precios globales
- Cálculo de descuentos
- Validación de inventario
- Procesamiento de pagos
Mejor:
BFF móvil
- Agrega datos
- Recorta payload
- Adapta la respuesta al cliente
Servicios de dominio
- Precios
- Inventario
- Pagos
Usar la pasarela como BFF
Algunos equipos agregan transformaciones específicas por cliente dentro de la configuración de la pasarela. Puede funcionar al principio, pero escala mal.
El problema no es técnico solamente; es organizacional. La pasarela suele pertenecer al equipo de plataforma. Si el equipo móvil necesita abrir tickets por cada cambio de payload, has creado el acoplamiento equivocado.
Construir un BFF cuando solo existe un cliente
Si solo tienes una aplicación web y ningún otro cliente divergente, empieza con una API compartida. Añade un BFF cuando exista una necesidad real: por ejemplo, una app móvil con patrones de datos y rendimiento diferentes.
Olvidar el contrato
Cada BFF y cada ruta expuesta por la pasarela es una API. Necesita:
- Contrato definido.
- Ejemplos de request/response.
- Pruebas.
- Mocks.
- Documentación.
Si no defines el contrato, el BFF “delgado” se convierte en una caja negra. Consulta qué es un contrato de API para entender por qué importa.
Dónde Encaja Apidog
Ya sea que una solicitud pase por una pasarela de API, por un BFF o por ambos, cada capa expone un contrato de API. Apidog es donde diseñas, pruebas, simulas y documentas esos contratos. No construye, aloja ni reemplaza una pasarela o un BFF; proporciona un espacio de trabajo para las superficies de API que esas capas exponen.
Flujo práctico con Apidog:
-
Diseña el contrato
- Define endpoints del BFF o rutas expuestas por la pasarela.
- Modela requests, responses, errores y esquemas.
- Genera OpenAPI para que frontend y backend trabajen contra el mismo contrato.
-
Simula antes de implementar
- Crea mocks del BFF móvil o web.
- Permite que el equipo frontend avance sin esperar a todos los servicios descendentes.
- Aplica un flujo API-first.
-
Prueba como un cliente real
- Ejecuta escenarios contra endpoints expuestos por la pasarela.
- Valida autenticación, códigos de estado y forma del payload.
- Comprueba que la respuesta agregada del BFF sigue el contrato.
-
Publica documentación
- Documenta cada BFF y ruta de pasarela.
- Permite que otros equipos consuman la API sin leer la implementación.
Ejemplo mínimo de contrato para un endpoint de BFF:
openapi: 3.0.3
info:
title: Mobile BFF API
version: 1.0.0
paths:
/mobile/product-summary/{id}:
get:
summary: Devuelve el resumen de producto para la app móvil
parameters:
- name: id
in: path
required: true
schema:
type: string
responses:
"200":
description: Resumen de producto
content:
application/json:
schema:
type: object
required:
- id
- name
- available
- price
properties:
id:
type: string
name:
type: string
image:
type: string
format: uri
available:
type: boolean
price:
type: object
properties:
amount:
type: number
currency:
type: string
El patrón que elijas es una decisión de arquitectura. El contrato que cada capa expone es una constante. Apidog ayuda a mantener esos contratos diseñados, probados, simulados y documentados, sin importar cómo conectes tus BFFs y pasarelas.
Prueba Apidog gratis para diseñar y simular tus contratos de BFF y pasarela antes de escribir una línea de código de backend.
Preguntas Frecuentes
¿Es un BFF un tipo de pasarela de API?
No. Se superponen en que ambos pueden enrutar y agregar, pero un BFF pertenece al equipo de frontend y está adaptado a una experiencia concreta. Una pasarela de API es de propiedad centralizada y sirve a todos los clientes de forma uniforme. Normalmente, el BFF se sitúa detrás de la pasarela.
¿Puedo usar un BFF sin una pasarela de API?
Sí, pero a escala suele ser mala idea. Sin pasarela, cada BFF tendría que reimplementar autenticación, limitación de velocidad y observabilidad. Eso genera duplicación e inconsistencias.
¿Cuántos BFFs debería tener?
Sigue la regla de Sam Newman: “una experiencia, un BFF”. Crea un BFF separado para cada frontend significativamente diferente. Clientes similares mantenidos por el mismo equipo, como iOS y Android, pueden compartir uno.
¿Un BFF reemplaza mi pasarela de API?
No. Son capas complementarias. La pasarela aplica políticas uniformes en el borde; el BFF modela datos para un cliente específico detrás de ella.
¿Cuándo no debería construir un BFF?
Omítelo cuando todos los clientes realizan solicitudes similares, cuando solo existe un cliente, o cuando una capa GraphQL con resolutores por frontend ya permite a los clientes obtener exactamente los datos que necesitan.
¿Dónde pertenecen la autenticación y la limitación de velocidad?
En la pasarela. Son preocupaciones transversales que deben ser uniformes para todos los clientes. Ponerlas en el BFF duplica lógica e invita a la desviación de políticas.
Top comments (0)