Un Backend para Frontend (BFF) es un servicio de backend dedicado construido para un frontend específico. En lugar de que cada cliente (web, iOS, Android, terceros) se comunique con el mismo backend de propósito general, cada uno obtiene su propia capa del lado del servidor que agrega y reformula los datos de sus microservicios exactamente en la carga útil que esa interfaz necesita.
Sam Newman nombró y popularizó el patrón en 2015, basándose en el trabajo realizado en SoundCloud. Más de una década después, el patrón BFF sigue siendo una herramienta estándar para equipos que ejecutan microservicios detrás de múltiples aplicaciones cliente, y Microsoft lo documenta como un patrón central de arquitectura en la nube.
El problema que resuelve un BFF
Imagine un sistema que comenzó con una única aplicación web y un único backend. El backend exponía puntos finales REST, la aplicación web los consumía y la vida era sencilla. Luego la empresa lanzó una aplicación móvil. Luego una integración con un socio. Luego un widget para un reloj inteligente. De repente, cuatro clientes muy diferentes están extrayendo datos del mismo backend, y ese backend está tratando de complacer a todos a la vez.
Esto crea dos problemas recurrentes.
Sobrecarga y subcarga de datos (Over-fetching y under-fetching). Un punto final de propósito general devuelve una forma fija de datos. Un panel de control de escritorio podría querer el registro completo del cliente con el historial de pedidos, recomendaciones y configuraciones de cuenta en una sola respuesta. Una aplicación móvil en una conexión celular inestable quiere tres campos y nada más. Cuando ambos acceden al mismo punto final, uno de ellos obtiene la cantidad incorrecta de datos. El cliente móvil descarga una carga útil inflada que tiene que descartar (over-fetching) o tiene que realizar varios viajes de ida y vuelta adicionales para ensamblar lo que necesita (under-fetching).
Clientes "charlatanes" (Chatty clients). Cuando un backend no está adaptado a una pantalla, el cliente lo compensa realizando muchas llamadas. Una pantalla de inicio móvil que necesita datos de perfil, un recuento de notificaciones y un feed podría disparar tres o cuatro solicitudes separadas a tres o cuatro microservicios, para luego unir los resultados en el dispositivo. Cada viaje de ida y vuelta adicional cuesta latencia y batería, y la lógica de orquestación se filtra al cliente, donde es difícil de probar y versionar.
La tensión principal es tanto organizacional como técnica. Un backend compartido tiene demandas contrapuestas de cada equipo de frontend. Un cambio de un equipo debe ser validado contra las necesidades de todos los demás equipos antes de ser implementado, lo que convierte al backend en un cuello de botella y una fuente de fricción entre equipos.
Cómo funciona el patrón BFF
El patrón BFF introduce una fina capa del lado del servidor que se interpone entre un frontend y sus servicios descendentes. Cada interfaz obtiene su propio backend.
[ Aplicación web ] ---> [ BFF web ] ---\
[ Aplicación iOS ] ---> [ BFF iOS ] -----> [ Microservicios ]
[ Aplicación Android] ---> [ BFF Android ] ---/
Cada BFF realiza tres tareas para su cliente:
- Agregación. Llama a los microservicios descendentes que la pantalla necesita y combina sus respuestas, de modo que el cliente realiza una solicitud en lugar de cinco. Esto es agregación de API aplicada a una única experiencia de usuario. Si desea la versión general de esa idea, consulte nuestra explicación sobre el patrón agregador de API.
- Remodelación. Recorta campos, renombra elementos a términos amigables para el cliente, aplana estructuras anidadas y formatea valores de la manera que la interfaz espera. El BFF móvil devuelve cargas útiles ligeras; el BFF de escritorio devuelve cargas útiles ricas.
- Traducción. Maneja preocupaciones específicas del cliente, como la estrategia de paginación, el almacenamiento en caché de respuestas ajustado a ese cliente y las opciones de protocolo, sin imponer esas decisiones a los servicios compartidos subyacentes.
Los microservicios descendentes permanecen de propósito general y agnósticos al frontend. Exponen capacidades limpias y reutilizables. El BFF es donde reside la adaptación específica del cliente, lo que mantiene esa lógica fuera tanto de los microservicios como de la aplicación cliente. Si es nuevo en la capa de servicio subyacente, nuestra descripción general de microservicios versus APIs y el cambio de una aplicación monolítica a microservicios le proporciona el contexto.
Un BFF por experiencia de cliente
La guía principal de Newman es breve: una experiencia, un BFF. Si sus aplicaciones iOS y Android ofrecen experiencias significativamente diferentes, dele a cada una su propio BFF. Si una aplicación web y una aplicación móvil divergen, se aplica la misma regla.
El objetivo de la regla es mantener cada BFF enfocado. En el momento en que un solo BFF intenta servir a dos clientes con necesidades diferentes, comienza a acumular lógica condicional ("si es móvil, devuelve esto; si es web, devuelve aquello"), y se vuelve a un backend de propósito general con los mismos problemas de coordinación. Un BFF enfocado se mantiene pequeño, que es la propiedad que hace que todo el patrón valga la pena.
Existe una excepción sensata que el propio Newman extrae de SoundCloud: cuando un equipo posee dos clientes similares, como aplicaciones iOS y Android que comparten casi la misma experiencia, puede ser razonable compartir un único BFF móvil entre ellos. El factor decisivo es la propiedad y la similitud, no los nombres de las plataformas. La regla es un valor predeterminado, no una ley.
La propiedad pertenece al equipo de frontend
Un BFF no es una capa que el equipo de la plataforma construye y entrega. El equipo de frontend que posee el cliente, posee su BFF. Esta es la segunda mitad de lo que hace que el patrón funcione.
Cuando el equipo de frontend es propietario del BFF, controla su cadencia de lanzamiento, elige su lenguaje y entorno de ejecución, prioriza su backlog y envía los cambios al cliente y a su servicio de respaldo de forma conjunta. Un cambio en la interfaz de usuario que necesita un nuevo endpoint agregado no requiere presentar un ticket a un equipo de backend separado y esperar a que este lo atienda en su cola. El equipo que siente el dolor es el propietario de la solución.
Esta autonomía es la verdadera victoria. El BFF mueve el límite para que las decisiones específicas del cliente sean tomadas por las personas responsables del cliente, que es exactamente donde el pensamiento de conectividad dirigida por API sitúa el nivel de "experiencia".
BFF vs. API Gateway
Esta es la comparación en la que la mayoría de los equipos tropiezan, porque un BFF y un API Gateway se ven similares en un diagrama. Ambos se sitúan entre clientes y servicios. Ambos pueden enrutar y agregar. Pero responden a preguntas diferentes.
Un API gateway es un punto de entrada de propósito general que maneja preocupaciones transversales para todo el tráfico: autenticación, limitación de velocidad, enrutamiento, terminación TLS y registro de solicitudes. Es propiedad de un equipo de plataforma o infraestructura y es deliberadamente agnóstico al cliente. Una única pasarela sirve a todos de la misma manera.
Un BFF es lo opuesto. Es específico del cliente por diseño, propiedad de un equipo de frontend, y su propósito principal es ser diferente para cada interfaz. Es el lugar donde reside la adaptación de la carga útil de un cliente, no un cuello de botella compartido.
Los dos no son rivales. En un diseño de producción común, una puerta de enlace API se sitúa en la parte delantera, manejando la autenticación, la limitación de velocidad y la monitorización de todo el tráfico, y luego enruta cada cliente a su BFF dedicado detrás de la puerta de enlace. La arquitectura de referencia de Microsoft muestra exactamente esto: una puerta de enlace que gestiona las preocupaciones transversales, con un BFF sin servidor por cliente detrás de ella. Utilice la puerta de enlace para lo que es igual en todos los clientes, y un BFF para lo que es diferente. (Cubrimos la versión profunda de este contraste en un artículo aparte; aquí basta con saber que se sitúan en diferentes capas y satisfacen diferentes necesidades).
Para el panorama de pasarelas circundantes, estas comparaciones publicadas son útiles: API management vs API gateway, API gateway vs load balancer y service mesh vs API gateway.
Cuándo usar un BFF
El patrón resulta útil cuando se cumplen estas condiciones:
- Tienes múltiples clientes, genuinamente diferentes. Web más móvil más una integración con socios, cada uno con necesidades de datos distintas. Cuanto más divergen las experiencias, más ayuda un BFF.
- Un backend compartido se ha convertido en un cuello de botella. Si cada cambio de frontend fuerza una negociación entre equipos, dividir la adaptación específica del cliente en BFFs por equipo elimina el coste de coordinación.
- Quieres cargas útiles optimizadas para el cliente. El móvil necesita respuestas ligeras y caché agresivo; el escritorio quiere datos agregados y ricos. Un BFF te permite optimizar cada uno sin compromisos.
- Un lenguaje se adapta mejor a un frontend. Un equipo puede construir su BFF en el entorno de ejecución que se adapte a su cliente, independientemente de lo que usen los otros BFFs.
Cuándo no usar un BFF
El patrón no es gratuito, y hay casos claros en los que añade costes sin beneficio:
- Solo tienes un cliente. Con una única interfaz, un BFF es solo un salto extra. Construye un backend normal.
- Tus clientes hacen las mismas solicitudes. Si la web y el móvil quieren datos casi idénticos en la misma forma, los BFFs separados duplican el esfuerzo sin ningún beneficio. Consolida en su lugar.
- GraphQL ya resuelve tu problema de forma. Con GraphQL, cada cliente consulta exactamente los campos que necesita desde un único endpoint, lo que cubre gran parte de lo que un BFF hace para dar forma a la carga útil. Si tienes una capa GraphQL con resolvedores específicos para el frontend, un nivel de BFF separado a menudo no añade valor. Consulta qué es GraphQL para juzgar si encaja antes de añadir un nivel de BFF.
- Una pasarela más microservicios es suficiente. Para sistemas más sencillos, una pasarela API delante de microservicios bien diseñados puede ofrecer resultados aceptables sin una capa dedicada por cliente.
Las desventajas honestas
Incluso cuando un BFF es la opción correcta, se incurre en costos reales. Adoptar el patrón con los ojos bien abiertos es parte de usarlo bien.
Duplicación de código. Este es el principal compromiso, y la documentación de Microsoft lo señala directamente. Cuando tres BFFs necesitan llamar a la misma comprobación de autenticación o formatear la misma fecha de la misma manera, esa lógica tiende a escribirse tres veces. Se está intercambiando duplicación por personalización. La solución es la disciplina: mantenga la lógica genuinamente compartida en bibliotecas que los BFFs importen, y reserve el BFF en sí para la adaptación específica del cliente. Empuje las preocupaciones verdaderamente transversales (autenticación, limitación de velocidad, monitoreo) a la puerta de enlace en lugar de volver a implementarlas por cada BFF.
Más servicios que operar. Cada BFF es otra unidad desplegable con su propio ciclo de vida, pipeline, rotación de guardia y superficie de seguridad. Más servicios significan más sobrecarga operativa.
Un salto de red adicional. Los clientes ya no se comunican directamente con los servicios. El BFF añade un salto, y eso puede añadir latencia. Suele ser una compensación que vale la pena porque el BFF elimina varios viajes de ida y vuelta del cliente, pero es un coste que hay que medir, no asumir.
Riesgo de que el BFF se infle. Si un BFF comienza a servir a múltiples clientes o a absorber lógica de negocio que pertenece a los microservicios, vuelve a ser el backend de propósito general del que se intentaba escapar. Manténgalo delgado.
Mantener los contratos BFF sincronizados con Apidog
La parte difícil de ejecutar BFFs en la práctica son los contratos. Cada BFF expone su propia API orientada al cliente, y también depende de los contratos de los microservicios debajo de ella. Eso es un montón de interfaces en movimiento a través de equipos que poseen diferentes capas, y la deriva entre ellas es donde provienen los errores y los clientes rotos.
Aquí es donde Apidog encaja en el flujo de trabajo. Apidog es una plataforma de diseño, pruebas, simulación y documentación de API, por lo que el contrato de API de cada BFF tiene un único hogar en el que los equipos de frontend y backend pueden trabajar:
- Diseñe el contrato primero. Defina cada endpoint de BFF y su esquema de solicitud y respuesta en el diseñador visual de Apidog con OpenAPI debajo, para que la forma orientada al cliente se acuerde antes de que se escriba el código. Este es el enfoque de diseño de API contract-first aplicado a la capa BFF, y mantiene el contrato de API explícito.
- Simúlelo antes de que exista. El equipo de frontend puede empezar a construir sobre un mock inteligente de Apidog del BFF el día en que se acuerda el contrato, sin esperar a que el BFF o sus servicios descendentes estén listos.
- Pruebe el contrato. Las pruebas automatizadas y las aserciones de Apidog verifican que cada BFF devuelve la carga útil agregada y remodelada que su cliente espera, y se ajustan a la CI para que un cambio descendente que rompa una respuesta de BFF sea detectado a tiempo.
- Documente para ambas partes. Apidog genera automáticamente documentos interactivos a partir del contrato, de modo que el equipo de frontend que lee la API del BFF y el equipo de backend propietario de los servicios subyacentes comparten una única fuente de verdad.
Para ser claros sobre el alcance: Apidog no construye, aloja ni ejecuta su BFF, y no es una puerta de enlace API. Es donde usted diseña, simula, prueba y documenta el contrato API que cada BFF respalda, que es lo que mantiene a los equipos de frontend y backend sincronizados a medida que los BFF evolucionan. Tratar cada BFF como un producto con un contrato estable y bien documentado es lo que hace que el patrón sea sostenible.
Preguntas frecuentes
¿Es un BFF un microservicio? Un BFF es un servicio del lado del servidor, y en una configuración de microservicios, generalmente funciona como tal. Pero su función es diferente a la de un microservicio típico. Un microservicio posee una capacidad de negocio y es agnóstico al cliente; un BFF posee la experiencia de un cliente y existe para agregar y remodelar esos microservicios para ese cliente. Es un servicio de capa de experiencia, no un servicio de capacidad de negocio.
¿Cuántos BFFs debería tener? El valor predeterminado es uno por cada experiencia de cliente distinta: uno para la web, uno para iOS, uno para Android, y así sucesivamente. Combina dos solo cuando un mismo equipo sea propietario de clientes con necesidades casi idénticas. Divide más cuando un BFF empiece a acumular lógica condicional por cliente.
¿GraphQL reemplaza el patrón BFF? Puede hacerlo, para la parte de la conformación de la carga útil. GraphQL permite a cada cliente solicitar exactamente los campos que necesita desde un único endpoint, lo que cubre el "over-fetching" y el "under-fetching" sin necesidad de un backend por cliente. Si tienes GraphQL con resolvedores específicos para el frontend, una capa separada de BFF a menudo añade poco valor. Los BFFs siguen siendo útiles cuando necesitas orquestación por cliente, traducción de protocolos o elecciones de tiempo de ejecución que un servidor GraphQL compartido no puede proporcionar fácilmente.
¿Puedo usar un BFF y un API Gateway juntos? Sí, y es común. El API gateway gestiona las preocupaciones compartidas entre todos los clientes, como la autenticación, la limitación de velocidad y la monitorización, y enruta el tráfico al BFF correcto. Cada BFF gestiona lo que es específico de su cliente. Se sitúan en capas diferentes y realizan trabajos distintos.
¿Quién debería ser el propietario del BFF? El equipo de frontend que es propietario del cliente. Esa propiedad es fundamental para el patrón. Permite al equipo lanzar cambios de interfaz de usuario y los endpoints de respaldo juntos, elegir su propio entorno de ejecución y avanzar sin esperar en la cola de un equipo de backend separado.
¿Un BFF añade latencia? Añade un salto de red, lo que tiene un coste. En la práctica, suele reducir la latencia total del cliente, ya que reemplaza varios viajes de ida y vuelta del cliente al servicio por una única solicitud del cliente al BFF y permite que el BFF llame a los servicios en paralelo cerca de ellos. Mídalo para su carga de trabajo en lugar de asumir una cosa u otra.