¿Qué es el Backend para Frontend (BFF)?

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.