Backend para Frontend - BFF vs API Gateway

Backend para Frontend (BFF), del inglés Backend for Frontend, es un patrón arquitectónico que consiste en crear un servicio backend específico y a medida para cada tipo de interfaz cliente: uno para la web, otro para la app móvil, otro para integraciones de terceros, etc. En lugar de un único backend genérico que sirva a todos por igual, cada frontend habla con un backend pensado exactamente para sus necesidades.

El patrón fue formalizado por Sam Newman y popularizado por el equipo de SoundCloud, que necesitaba servir de forma eficiente a clientes muy distintos (web de escritorio y aplicaciones móviles) sin sobrecargar a ninguno con datos que no usaba.

El problema que resuelve el BFF aparece cuando un mismo backend tiene que satisfacer a frontends con requisitos muy diferentes. Una app móvil quiere respuestas ligeras, con pocos campos y pocas llamadas (porque la red es lenta y la batería importa). Una web de escritorio puede permitirse respuestas más ricas. Un cliente de terceros necesita un contrato estable y versionado.

Forzar a todos a usar la misma API genérica produce respuestas infladas, llamadas innecesarias y un backend lleno de condicionales por tipo de cliente. El BFF da a cada frontend justo lo que necesita, ni más ni menos.

El BFF introduce una capa intermedia entre los frontends y los servicios de negocio (o microservicios). Cada BFF:

1. Recibe las peticiones de su frontend concreto.
2. Orquesta llamadas a los servicios downstream (varios microservicios, bases de datos, APIs externas).
3. Agrega y transforma los datos en el formato exacto que ese frontend espera (aggregation), evitando que el cliente haga múltiples llamadas.
4. Devuelve una respuesta a medida, sin campos sobrantes.

Es habitual que el equipo que desarrolla cada frontend sea también el dueño de su BFF, lo que reduce la coordinación entre equipos y acelera los cambios.

El BFF se confunde a menudo con un API Gateway, pero resuelven problemas distintos:

No son excluyentes: muchos sistemas usan un API Gateway como punto de entrada y varios BFF detrás, cada uno especializado en su cliente.

• Mejor rendimiento por cliente: cada frontend recibe respuestas optimizadas para su contexto (menos datos, menos llamadas en móvil).
• Independencia de los equipos: el equipo de cada frontend evoluciona su BFF sin pisar a los demás ni esperar a un backend compartido.
• Frontends más simples: la lógica de agregación y transformación vive en el BFF, no en el cliente.
• Evolución desacoplada: cambiar la app móvil no obliga a tocar la web ni el backend principal.
• Seguridad afinada: cada BFF expone solo lo que su frontend necesita, reduciendo la superficie de ataque.

El BFF no es gratis. Sus principales contrapartidas:

• Duplicación de lógica: código parecido repetido en varios BFF si no se factoriza bien lo común.
• Más servicios que mantener: cada BFF es un despliegue, una pipeline y un punto de fallo más.
• Sobreingeniería: si solo tienes un frontend, un BFF añade complejidad sin beneficio.

El patrón brilla cuando hay varios clientes con necesidades divergentes (típicamente web + móvil + terceros). Con un único cliente, suele ser preferible una API bien diseñada.

¿Cuándo conviene introducir un BFF?

Cuando empiezas a llenar tu backend de condicionales del tipo "si es móvil devuelve esto, si es web devuelve aquello", o cuando un frontend tiene que hacer muchas llamadas y combinar datos a mano. Son señales de que cada cliente pide algo distinto.

¿Un BFF es un microservicio?

Funcionalmente se parece (es un servicio desplegable de forma independiente), pero su rol es de adaptación y orquestación para un frontend, no de implementar lógica de negocio de dominio.

¿Cuántos BFF debería tener?

Lo habitual es uno por experiencia de cliente claramente diferenciada: uno para web, uno para móvil, uno para integraciones públicas. Crear un BFF por pantalla o por equipo suele ser excesivo.

Un API Gateway es un componente de infraestructura que actúa como punto de entrada único para todas las peticiones de los clientes hacia los servicios backend. Funciona como un proxy inverso que recibe las solicitudes, las enruta al servicio correspondiente y devuelve la respuesta al cliente.

El API Gateway centraliza funcionalidades transversales como autenticación, autorización, rate limiting, logging, transformación de peticiones y balanceo de carga, evitando que cada microservicio implemente estas capacidades de forma independiente.

Entre las funcionalidades principales se encuentran: enrutamiento de peticiones, composición de respuestas de múltiples servicios, transformación de protocolos, caché de respuestas, circuit breaking y gestión de versiones de APIs.

Algunos API Gateways populares incluyen Kong, AWS API Gateway, Apigee, NGINX y Traefik. Cada uno ofrece diferentes capacidades según el caso de uso.

Un API Gateway puede convertirse en un punto único de fallo si no se configura con alta disponibilidad. También puede añadir latencia adicional a las peticiones al ser un salto más en la red.