Backend for Frontend
Adaptación para una experiencia cliente
Backend for Frontend, o BFF, es un patrón que sitúa una adaptación backend enfocada en las necesidades de una experiencia o interfaz cliente. Puede reunir capacidades, ajustar payloads y coordinar interacciones para esa experiencia. Su identidad está en ese foco; agregar un servidor entre browser y backend no basta para establecerlo.
Sam Newman, Backends For Frontends, lo presenta explícitamente como patrón y describe servicios de borde especializados para interfaces y partes externas. En su texto atribuye el término a Phil Calçado, de SoundCloud. Destaca cercanía entre experiencia y backend y mantenimiento habitual por el mismo equipo. Esa observación no impone una estructura organizativa universal ni un servidor por pantalla.
kind: pattern conserva esa clasificación editorial y coincide con Backends for Frontends de Microsoft. No convierte en definición universal todas las recomendaciones o productos Azure de su ejemplo. frontend-and-client-architecture lo organiza junto a decisiones cliente, aunque el BFF ejecute del lado servidor.
Qué divergencia intenta resolver
Un backend general puede acumular demandas diferentes de Web, aplicación móvil y otros consumidores. Cambian payload, secuencia de interacciones, agregación necesaria y ritmo de evolución. Adaptar todo en una superficie común puede bloquear cambios entre experiencias; hacer cada adaptación en los clientes también tiene costos.
En Commerce, Web podría necesitar producto, promociones, resumen del carrito y estado de orden juntos para un recorrido. Mobile podría requerir otra información o secuencia. Eso justifica investigar Web BFF y Mobile BFF, no crearlos automáticamente: medir divergencia real, trabajo repetido y coordinación. Mobile no significa siempre red lenta ni payload mínimo.
El acoplamiento a la experiencia es deliberado. Cambiar el checkout puede cambiar su contrato BFF sin arrastrar APIs de otros clientes. El costo se desplaza a mantener otra unidad y sus integraciones; no desaparece. Si varios clientes solicitan esencialmente lo mismo, un backend común puede seguir siendo suficiente.
Frontera de adaptación y autoridad de dominio
El BFF puede seleccionar datos, adaptar protocolos, reunir respuestas, aplicar defaults específicos y coordinar llamadas para representar una interacción. Una regla sobre qué panel mostrar no tiene el mismo alcance que decidir si un pago puede autorizarse. data-ownership conserva autoridad semántica sobre hechos y cambios válidos del negocio.
En Checkout MFE → Web BFF → Payments, el BFF traduce una solicitud o respuesta; Payments sigue declarando el resultado comercial. Orders e Inventory conservan sus compromisos. Recibir información, cachearla o presentarla no concede al BFF permiso para escribir tablas ajenas ni reinterpretar desconocido como autorizado.
No se prohíbe toda lógica por estar en un BFF: delimitar responsabilidad, variación y autoridad. Duplicar una invariante de pagos en Web y Mobile puede producir decisiones contradictorias. Si aparece una capacidad de negocio común, revisar su owner apropiado. Evitar que servicios de dominio queden reducidos accidentalmente a persistencia detrás de toda lógica acumulada en el borde.
Roles parecidos con preguntas diferentes
La tabla separa preguntas del Atlas, no exige procesos diferentes para cada rol. Una realización puede combinar funciones, conservando sus compromisos.
| Rol o mecanismo | Foco que conviene distinguir del BFF |
|---|---|
| API Gateway | Entrada y políticas compartidas entre consumidores y capacidades. |
| Reverse proxy | Reenvío y routing hacia servidores. |
| Façade | Superficie simplificada de un subsistema; no exige foco en una experiencia. |
| Agregador | Reunir resultados; por sí solo no explica ownership cliente. |
| GraphQL | Consulta y contrato de datos; no determina quién adapta cada experiencia. |
| Runtime SSR | Producir representación; no equivale a adaptar capacidades backend. |
| Servicio de borde genérico | Ubicación o función de acceso; no implica especialización cliente. |
Microsoft describe API gateways con routing y preocupaciones transversales como autenticación y rate limiting, además de posibles agregaciones. Pueden coexistir delante de BFFs. Un gateway especializado puede realizar parte del patrón; el producto o nombre de infraestructura no decide qué responsabilidad tiene.
Un facade-pattern puede simplificar acceso sin estar dedicado a una experiencia. Un proxy que solo reenvía tampoco obtiene automáticamente esa especialización. Incluso si un BFF usa internamente ambas ideas, conviene explicar qué cambio del cliente lo motiva y qué decisiones protege frente al backend.
GraphQL, rendering y protocolos
GraphQL permite expresar consultas sobre un schema y solicitar campos pertinentes. No prescribe un backend por cliente ni impide implementarlo. Un BFF puede exponer GraphQL, REST, RPC u otro contrato; elegir protocolo no determina su frontera ni elimina adaptación de interacciones y permisos.
Microsoft señala que GraphQL con resolvers específicos de frontend puede hacer innecesaria una capa BFF separada. Conservar ese contexto evita afirmar que GraphQL siempre la reemplaza o que siempre hay que agregar otra. La pregunta es dónde quedan resueltas las necesidades reales, no cuántas cajas tiene el dibujo.
rendering-strategies distingue producción de HTML y activación cliente. Un runtime SSR puede llamar un BFF, consultar capacidades directamente o alojar ambos roles. Un cliente CSR también puede consumir BFF. Ni SSR ni un servidor de templates definen por sí mismos el patrón. Esta separación permite cambiar rendering sin asumir automáticamente otro reparto de autoridad.
Granularidad, ownership y deployment
Un BFF por experiencia no significa uno por componente, pantalla o dispositivo físico. iOS y Android podrían compartirlo si sus interacciones y responsables lo justifican; experiencias divergentes pueden necesitar otra frontera. Newman discute alternativas según interfaces y equipos. No extraer de ellas una cuenta universal de servicios.
granularity permite evaluar ambos extremos: un backend para todo puede recrear el cuello de botella; un BFF por fragmento puede multiplicar coordinación y operación. Que el equipo cliente pueda cambiar su adaptación facilita autonomía, pero necesita responsables con capacidad para operar código servidor y colaborar con capacidades de negocio.
deployment pregunta si BFF y cliente se actualizan juntos o por separado. Versiones ya distribuidas pueden seguir usando un contrato anterior; una entrega nueva debe respetar consumidores soportados. deployability necesita evidencia sobre compatibilidad, rollout y recuperación, además de otro pipeline. Separar repositorios o containers no elimina coordinación contractual.
mobile-architecture hace especialmente visible esa diferencia: publicar un backend nuevo no actualiza las apps instaladas. Un Mobile BFF puede sostener adaptación para versiones soportadas, pero no elimina el problema de compatibilidad ni administra el lifecycle local del cliente. La necesidad de ese borde depende de divergencias concretas de experiencia, no del nombre de la plataforma.
Una llamada cliente puede abrir varias dependencias
communication conserva semántica de llamadas y fallos. Un request al BFF puede producir fan-out hacia Orders, Payments e Inventory. Ejecutar consultas independientes en paralelo puede reducir parte de la espera; otras dependen de resultados anteriores. Agregación no elimina trabajo ni garantiza latencia menor: añade salto, serialización, cómputo y límites del propio BFF.
web-performance permite contrastar el efecto de esa adaptación sobre TTFB, navegación y recorridos completos: menos llamadas desde browser no demuestra menor latencia extremo a extremo. El presupuesto de respuesta debe considerar dependencias y resultado útil para el cliente. deadline y timeout aportan límites distintos; retry necesita condiciones seguras y presupuesto. Repetir desde cliente, BFF y servicio puede amplificar carga. No imponer retries o fallback por el solo hecho de centralizar llamadas.
El BFF agrega una dependencia runtime para esa experiencia. Puede contener algunos fallos específicos y también convertirse en punto único de fallo. Backend compartido, gateway, cuotas o estado común pueden vincular experiencias aunque existan BFFs separados. Ni más cajas ni otro deployment prueban mejora de reliability.
Fallo parcial en Checkout
En este ejemplo propio, el resumen consulta Orders, Inventory y Payments. Payments excede la espera. El contrato debe explicar si puede mostrarse una representación parcial, si cierta sección queda pendiente o si toda la respuesta pierde utilidad. Son decisiones de producto y dominio, no una política universal del patrón.
No mostrar autorizado por ausencia de respuesta. Tampoco reutilizar sin contexto un estado anterior como evidencia de que el último intento terminó. idempotency ayuda cuando se permite repetir una operación con efectos; no convierte cualquier retry en seguro. Una respuesta parcial tiene que ser comprensible para el cliente, con incertidumbre visible donde importe.
Probar el mapping feliz no alcanza: revisar backend lento, rechazo, respuesta parcial, duplicación y versiones coexistentes. Correlacionar solicitudes y resultados permite localizar qué dependencia condicionó la experiencia. Esa evidencia importa aunque el frontend reciba un solo endpoint aparentemente simple.
Caché, estado y seguridad con alcance explícito
Una caché BFF puede reducir consultas o adaptar vigencia a una experiencia. Necesita fuente, variación por contexto, invalidación y significado de stale. No hace al BFF autoridad de precio o pago. client-state-management conserva otras responsabilidades: borradores, UI efímera, navegación y lifecycle de copias locales no quedan administrados automáticamente por ese servidor.
unidirectional-data-flow sigue organizando cambios cliente; el BFF organiza adaptación servidor. Que una llamada vuelva por la misma API no decide cómo una vista aplica resultados tardíos. Separar responsabilidades evita esperar que agregar BFF resuelva carreras, preservación de formularios o toda sincronización.
El BFF puede participar en contexto de sesión y forwarding de autorización; las capacidades pertinentes siguen necesitando controles adecuados. Algunas credenciales servidor pueden permanecer fuera del código browser, pero solo si la arquitectura evita exponerlas. El patrón no garantiza seguridad ni define por sí mismo autenticación. No se desarrolla aquí la variante especializada de BFF para OAuth en aplicaciones browser.
Micro Frontends y BFF: fronteras que no se cuentan juntas
micro-frontends divide y compone una experiencia mediante aplicaciones con autonomía de entrega. BFF adapta capacidades desde el servidor para una experiencia cliente. Commerce podría tener Browse, Checkout y Account como partes frontend y un Web BFF común. No hace falta crear un BFF para cada una ni un frontend para cada servicio de dominio.
Un equipo podría poseer una parte frontend y su adaptación servidor cuando eso ayude a cambiarla integralmente. También podría compartir BFF con experiencias suficientemente parecidas. Si la adaptación común empieza a exigir coordinación constante entre necesidades divergentes, revisar el límite. Si cada fragmento adquiere backend propio, evaluar el costo de fragmentación.
BFF aparece frecuentemente junto a Microservices; eso no establece que sean requisito universal. Capacidades de un backend monolítico también pueden necesitar adaptación cliente. MVC, MVP o MVVM pueden organizar internamente presentación sin decidir esa frontera. El patrón no sustituye arquitectura de dominio ni diseño interno.
Duplicación, costo y evolución
Mappings, agregaciones y utilidades repetidas entre BFFs pueden ser un costo aceptado para preservar evolución independiente. Extraer todo a una biblioteca común puede volver a acoplar releases. Duplicar reglas comerciales autoritativas tiene otro riesgo y merece revisar responsabilidad antes de tolerarlo por conveniencia.
interfaces ayuda a revisar ambos contratos: cliente–BFF y BFF–capacidad. Cambiar payload sin examinar significado, errores y consumidores puede romper el recorrido. Si el borde concentra reglas ajenas, equipos bloqueados y cambios sin relación, el problema es desajuste de responsabilidades y dependencias; llamarlo monolito no reemplaza ese diagnóstico.
operability y cost-efficiency incorporan compute, logs, deployments, atención de incidentes y mantenimiento. Un salto adicional puede valer la pena si reduce conversaciones o adaptación dispersa, pero necesita evidencia. Una experiencia única sencilla, clientes equivalentes o una capa existente que ya resuelve la necesidad pueden hacer innecesario otro BFF.
Como transición posible, Commerce puede introducir Web BFF en recorridos nuevos mientras los anteriores conservan acceso directo. strangler-fig aporta preguntas sobre coexistencia y retirada, sin ser requisito del patrón. Registrar qué contrato sigue activo y quién lo consume evita conservar indefinidamente dos caminos accidentales. Elegir el patrón requiere una necesidad cliente concreta y capacidad de sostener su costo.