Mobile y Web BFF.
Una llamada por pantalla. Cada canal pide lo que necesita.
Un mismo backend sirviendo a iOS, Android, web pública y partners genera fricción: cada cliente sobre-fetcha, hace N+1 calls, replica lógica de UI. Con un BFF (Backend for Frontend) por canal, MuleSoft entrega exactamente lo que esa pantalla necesita, en el formato que necesita, con compresión y versionado por cliente. La home de tu app pasa de ocho llamadas a una.
¿Qué resuelve un BFF con MuleSoft?
Cuando el front consume Process APIs o System APIs directo, termina sobre-fetchando, encadenando llamadas innecesarias y replicando lógica de UI en cada cliente. Un BFF por canal centraliza la composición, optimiza el contrato para esa pantalla y aísla a la app de la complejidad del backend. La promesa: una llamada por pantalla, payload mínimo, degradación graceful.
- Una Experience API por canal (iOS, Android, web, partner).
- Versionado por header — versiones distintas de la app reciben payloads distintos.
- Degradación parcial: si una Process API falla, la respuesta entrega lo que pudo y la app se adapta.
- Compresión, cache CDN y field selection para payloads mínimos.
Sistemas típicos involucrados
Las familias de sistemas que conviven en una arquitectura BFF enterprise.
Front-ends
iOS y Android nativos, React Native, Flutter, web Next.js, Vue, Angular y PWA. Cada canal con sus restricciones de payload, latencia y batería.
Auth e identidad
Auth0, Okta, Cognito, Salesforce Identity o IdP custom para autenticación de usuarios finales y partners B2B.
Process APIs existentes
Catálogo de Process APIs ya construidas (customer-360-pa, accounts-pa, transactions-pa, marketing-pa) que el BFF orquesta sin duplicar.
CDN y observabilidad
Cloudflare o Akamai en el edge, New Relic o Datadog para APM por canal y por versión del cliente.
Arquitectura objetivo
Una Experience API por canal sobre el mismo stack de Process y System APIs.
+----------------+ +----------------+ +----------------+ +-------------+
| iOS App | | Android App | | Web (Next.js) | | Partner API |
+--------+-------+ +--------+-------+ +--------+-------+ +------+------+
| | | |
v v v v
+--------------+ +---------------+ +--------------+ +-------------+
| ios-bff-eapi | | android-bff- | | web-bff-eapi | | partner-eapi|
| | | eapi | | | | |
+------+-------+ +-------+-------+ +------+-------+ +------+------+
| | | |
+----+--------------+--+--------------+------------------+
|
v
+----------------+
| Process APIs |
+-------+--------+
|
v
+----------------+
| System APIs |
+----------------+System APIs
Las System APIs no cambian: cada sistema fuente tiene su contrato canónico estable. El BFF se apoya en ellas a través de la capa de Process, sin acceder directo a sistemas core.
Process APIs
Las Process APIs siguen siendo las dueñas de la lógica de negocio: customer-360-pa, accounts-pa, transactions-pa. El BFF orquesta entre ellas, no decide.
Experience APIs (BFF)
Una por canal. ios-bff-eapi entrega home en una sola llamada, web-bff-eapi sirve dashboard con más data, partner-eapi expone contratos versionados con OAuth client credentials para integraciones B2B.
Flujo paso a paso
Cómo se sirve la home de la app móvil en una sola llamada.
- 1 El usuario abre la app móvil. La app envía GET /home con su JWT y el header X-App-Version con la versión instalada.
- 2 ios-bff-eapi valida el JWT, extrae customerId y la versión del cliente.
- 3 El BFF ejecuta scatter-gather a varias Process APIs: customer-360-pa para nombre, segmento y alertas; accounts-pa para balance; transactions-pa para últimas tres transacciones; marketing-pa para banner segmentado.
- 4 Cada llamada tiene su propio timeout y circuit breaker. El BFF tolera fallos parciales: marca la sección con _partial en lugar de fallar la respuesta completa.
- 5 Si la versión del cliente es >= 5.0, la respuesta incluye campos nuevos como loyaltyPoints. Si la versión es anterior, se omiten para no romper el cliente viejo.
- 6 El BFF aplica masking de datos sensibles: muestra los últimos cuatro dígitos de la cuenta, nunca el número completo.
- 7 Aplica field selection cuando el cliente envía ?fields= y reduce el payload al mínimo necesario.
- 8 Comprime la respuesta con gzip y la entrega con headers de cache CDN apropiados.
- 9 Si una Process API responde lento, el BFF entrega lo que pudo y la app muestra un placeholder en la sección afectada.
- 10 Cada respuesta lleva un correlationId que recorre BFF, Process APIs y System APIs para tracing distribuido en Anypoint Monitoring.
- 11 Latencia P95 objetivo: bajo 500 ms, con cache hit alto para los endpoints más calientes (home, dashboard, perfil).
Patterns aplicados
Los patrones que sostienen un BFF productivo y mantenible.
Backend for Frontend
Una Experience API por canal: iOS, Android, web, partner. Cada una optimizada para esa pantalla, ese cliente y esa autenticación.
API versioning por header
El header X-App-Version dirige la respuesta. Versiones nuevas reciben campos nuevos, versiones viejas siguen funcionando sin tocar.
Field selection
Query param ?fields= o GraphQL-style: el cliente pide solo los campos que va a usar y el BFF entrega un payload mínimo.
Degradación parcial
Cuando una Process API falla, el BFF entrega la respuesta con la sección afectada en null y un flag _partial para que el front se adapte.
Compression y cache CDN
Gzip por defecto, cache headers afinados por endpoint y CDN frontal cuando aplica para reducir RTT y consumo de batería.
Response shaping per device
iOS, Android y web reciben payload distinto del mismo dato: imágenes de tamaño correcto, listas truncadas y formatos serializados según la pantalla.
Cómo lo implementamos
Cinco fases del primer endpoint a un catálogo de BFFs por canal.
Mapeo de canales y dolor
Inventario de canales (iOS, Android, web, partner), análisis de payloads actuales, N+1 calls, lógica duplicada en clientes y oportunidades de consolidación. Entregables: assessment, métricas baseline de latencia y payload size.
Contratos por canal y versionado
Diseño del primer BFF, contrato de endpoints prioritarios (home, dashboard, perfil), política de versionado por header, plan de masking y field selection.
Construcción del primer BFF
Implementación del BFF con scatter-gather, fallbacks, compresión y cache. Tests MUnit, performance testing temprano, mock para los equipos de front que iteran en paralelo.
Hardening y rollout por canal
Hardening, CDN tuning, security review, load testing, observabilidad por versión del cliente. Go-live progresivo (web piloto, luego mobile) con hypercare focalizado.
Más canales, GraphQL opcional
Sumar nuevos BFFs (partner, internal staff), evaluar GraphQL como Experience API cuando los front teams piden flexibilidad, capacitar al equipo del cliente para gobernar contratos por canal con autonomía.
Requisitos del proyecto
Lo que tiene que estar disponible del lado del cliente para arrancar.
Datos mínimos
Process APIs existentes con contratos estables, métricas baseline de latencia y payload de los canales actuales y un equipo de front alineado con el modelo BFF.
Licencias y capacidades
Anypoint Platform, Anypoint Object Store para cache, IdP enterprise (Auth0, Okta, Cognito o Salesforce Identity) y CDN frontal cuando aplica.
Integraciones típicas
Process APIs ya construidas, APM (New Relic, Datadog, Splunk) integrado, mobile crash reporting alineado con el correlationId que entrega el BFF.
Pre-requisitos organizacionales
Sponsor de canales digitales, ownership claro por canal (iOS, Android, web), política de deprecation de versiones viejas y plan de comunicación con los equipos de front.
KPIs operativos
Las métricas que típicamente mejoran tras la implementación. Sin números de mercado: cada cliente fija su baseline.
| KPI | Qué mide | Por qué importa |
|---|---|---|
| BFF endpoint P95 | Latencia P95 de los endpoints calientes del BFF. | Una llamada lenta degrada la percepción de toda la app, incluso si los servicios upstream están sanos. |
| Partial response rate | Porcentaje de respuestas con secciones marcadas _partial por fallos downstream. | Mide cuánto cubre realmente el BFF cuando algo más cae, no solo el SLA de los servicios de fondo. |
| Cache hit rate por endpoint | Eficiencia del cache CDN y Object Store en los endpoints más calientes. | Define el costo operativo del BFF y el blindaje frente a picos de tráfico. |
| Error rate por client version | Errores observados desde versiones específicas del cliente. | Una versión recién publicada puede romperse y hay que detectarlo antes de que el negocio reclame. |
| Payload size P95 | Tamaño del JSON entregado a los endpoints principales. | Impacta en latencia de red, batería y data plan de los usuarios mobile. |
| Calls per screen | Cantidad de llamadas que el cliente hace para pintar una pantalla. | El compromiso del BFF es reducirlo a una. Es el indicador más honesto del valor entregado. |
Time-to-value: primer BFF en producción tras 8 a 12 semanas desde el kickoff, con métricas observables en las primeras semanas.
Cómo se mide: dashboard entregado por Solu sobre Anypoint Monitoring, complementado con New Relic, Datadog o Splunk según el stack del cliente.
Preguntas frecuentes
Conviene cuando hay varios canales digitales con necesidades distintas, sobre-fetch evidente, N+1 calls o lógica de UI replicada en cada cliente. No conviene cuando hay un solo canal y los Process APIs ya cumplen exactamente lo que el front necesita: agregar un BFF en ese caso suma latencia sin valor.
REST sigue siendo el camino más rápido cuando el catálogo de canales es estable y los contratos cambian poco. GraphQL gana cuando hay muchos front teams pidiendo flexibilidad o cuando los payloads cambian seguido. MuleSoft soporta GraphQL vía DataGraph o resolvers custom y conviven sin problema con REST en el mismo stack.
Versionado por header X-App-Version. La nueva versión del BFF agrega campos nuevos y deja los viejos intactos. Nunca se remueve un campo en uso. Cuando una versión vieja queda sin soporte, se anuncia con tiempo y se monitorea su tráfico antes de deprecarla.
El BFF tiene timeouts por sección y un circuit breaker. Cuando se vence el timeout, devuelve la respuesta con la sección en null y un flag _partial. La app la lee y muestra un placeholder o esconde la sección sin romperse. El equipo recibe alerta sobre el SLA del Process API afectado.
El BFF expone endpoints idempotentes y headers de cache que la app puede aprovechar para modo offline. La estrategia exacta depende del cliente: la app usualmente cachea datos no críticos en local storage y revalida en cada apertura. El BFF no implementa lógica offline propia, pero entrega los contratos para que el front lo haga simple.
Una llamada por pantalla. Cada canal, lo justo y necesario.
Hablemos del estado de tus canales y diseñamos juntos el roadmap del primer BFF.