En arquitecturas distribuidas orientadas a servicios, el patrón Backend for Frontend (BFF) —popularizado inicialmente por Sam Newman— surge como respuesta a la tensión constante entre dos necesidades opuestas:

  1. La necesidad del backend de exponer servicios genéricos, cohesivos y centrados en el dominio del negocio.
  2. La necesidad del frontend (web, apps móviles, kioscos o integraciones B2B) de consumir payloads compactos, agregados y optimizados para una interfaz de usuario o dispositivo específico.

Intentar resolver ambas demandas con una única capa de "API pública compartida" suele derivar en dos problemas clásicos: sobrecarga de red en dispositivos móviles (over-fetching / under-fetching) o endpoints acoplados a vistas particulares que terminan degradando el diseño de los microservicios core.

1. El Problema: La API Única de Propósito General

Imaginemos un flujo omnicanal estándar (por ejemplo, el detalle de un cliente en checkout o CRM):

  • App Móvil: Requiere renderizar rápido en conexiones 4G/5G inestables. Necesita el nombre del cliente, su saldo de puntos y los 3 últimos pedidos. Quiere un payload mínimo (< 10 KB) en una sola llamada HTTP/2.
  • Portal Web Desktop: Dispone de mayor ancho de banda y pantalla. Necesita además el historial completo de facturación, direcciones fiscales guardadas y preferencias de notificación.

¿Qué ocurre sin un BFF?

  • Estrategia "Un microservicio por vista": El cliente móvil realiza 4 o 5 llamadas encadenadas (/users/{id}, /loyalty/{id}, /orders?limit=3, /discounts). Esto multiplica la latencia por la suma del RTT (Round Trip Time) de cada conexión sobre redes móviles.
  • Estrategia "Endpoint monolítico multipropósito": Se crea un endpoint en el backend central que devuelve todo. El móvil descarta el 70% de los datos recibidos (over-fetching), consumiendo batería y cuota de datos innecesariamente.

2. Topología de la Solución: BFF + API Gateway

El patrón BFF introduce una capa intermedia donde cada experiencia de usuario tiene su propio backend de consumo, mantenido idealmente por el mismo equipo que construye la interfaz cliente.

flowchart TD
    subgraph Clients ["Clientes"]
        App["App Móvil (iOS / Android)"]
        Web["Web SPA (Desktop)"]
        Pos["Kiosco / POS"]
    end

    subgraph Edge ["Perímetro"]
        Gateway["API Gateway (e.g., Kong)"]
    end

    subgraph BFF_Layer ["Capa BFF"]
        BFF_Mobile["BFF Móvil (Node.js / Go)"]
        BFF_Web["BFF Web (Node.js / Go)"]
    end

    subgraph Core_Services ["Servicios Core"]
        S1["Customer Service"]
        S2["Loyalty / Points Service"]
        S3["Order Service"]
    end

    App --> Gateway
    Web --> Gateway
    Pos --> Gateway

    Gateway -->|/api/v1/mobile/*| BFF_Mobile
    Gateway -->|/api/v1/web/*| BFF_Web
    Gateway -->|/api/v1/pos/*| S3

    BFF_Mobile --> S1
    BFF_Mobile --> S2
    BFF_Mobile --> S3

    BFF_Web --> S1
    BFF_Web --> S2
    BFF_Web --> S3