“BFF vs. Pasarela de API” es uno de los enfrentamientos que más confusión generan en la arquitectura de microservicios. Los dos patrones parecen similares en un diagrama. Ambos se sitúan frente a tus servicios. Ambos toman una solicitud del cliente y la entregan a los backends. Por lo tanto, los equipos asumen que son opciones competidoras, eligen una y terminan metiendo responsabilidades equivocadas en ella.
No son competidores. Un Backend para Frontend (BFF) y una pasarela de API resuelven problemas diferentes, son propiedad de equipos diferentes y, muy a menudo, funcionan juntos en el mismo sistema. El BFF se sitúa detrás o junto a la pasarela, no en su lugar.
Esta guía traza la línea claramente. Aprenderás qué es realmente cada patrón, dónde se superponen, cuándo usar uno o ambos, y los errores que surgen al difuminarlos. A lo largo de todo el proceso, el contrato de la API es la constante: ya sea que una solicitud fluya a través de una pasarela, un BFF o ambos, cada capa expone una API que aún tienes que diseñar, probar, simular y documentar.
¿Qué es una Pasarela de API?
Una pasarela de API es un punto de entrada centralizado que se sitúa entre los clientes y tus servicios de backend. Cada solicitud llega a través de la pasarela, la cual aplica un conjunto consistente de preocupaciones transversales antes de enrutar la llamada.
Esas preocupaciones son las mismas para cada cliente y cada servicio:
- Enrutamiento: hacer coincidir una ruta entrante con el servicio ascendente correcto.
- Autenticación y autorización: validar tokens, rechazar llamantes no autorizados.
- Limitación de velocidad y estrangulamiento: proteger los backends de la sobrecarga y el abuso.
- Observabilidad: registrar solicitudes, emitir métricas, rastrear llamadas entre servicios.
- Terminación TLS, almacenamiento en caché y transformación de solicitudes: manejar la "fontanería" una sola vez, en un solo lugar.
La característica definitoria de la pasarela es que es de propósito general y de propiedad centralizada. Un equipo de plataforma o infraestructura la gestiona, y sirve a todos los clientes por igual. No le importa si el llamante es una aplicación móvil, una SPA web o una integración de socios; aplica las mismas políticas a todos.
Esto convierte a la pasarela en el hogar natural para las reglas a nivel de organización. Si quieres que cada solicitud sea autenticada de la misma manera, o que cada API tenga un límite de velocidad consistente, la pasarela lo aplica sin que cada servicio tenga que reimplementar la lógica. Para entender cómo esto difiere de las herramientas de plataforma más amplias, consulta Gestión de API vs. Pasarela de API.
¿Qué es un Backend para Frontend (BFF)?
Un Backend para Frontend, introducido por Sam Newman, invierte la orientación. En lugar de un backend de propósito general que sirve a cada cliente, construyes un backend por cada experiencia de usuario. La aplicación web obtiene un BFF web. La aplicación móvil obtiene un BFF móvil. Cada BFF está adaptado exactamente a un solo frontend. El patrón surgió del trabajo con microservicios, donde un único backend compartido que sirve a muchos clientes se convierte en el mismo tipo de cuello de botella que un monolito.
La regla general de Newman es "una experiencia, un BFF". Frontends significativamente diferentes obtienen su propio BFF; los similares (una aplicación iOS y Android mantenidas por el mismo equipo) pueden compartir uno.
La característica definitoria aquí es la propiedad y la forma. Un BFF está "estrechamente acoplado a una experiencia de usuario específica, y normalmente será mantenido por el mismo equipo que la interfaz de usuario", en palabras de Newman. El equipo de frontend es propietario de su BFF. Evolucionan el cliente y su backend juntos, sin esperar a que un equipo de backend separado apruebe cada cambio.
¿Qué hace realmente un BFF? Da forma a los datos para un cliente:
- Agregación: una pantalla móvil necesita datos de cinco microservicios. El BFF móvil llama a los cinco y devuelve una respuesta combinada, de modo que el teléfono realiza una sola ida y vuelta en lugar de cinco.
- Recorte y remodelación: el cliente móvil solo necesita tres campos de cuarenta. El BFF elimina el resto para ahorrar ancho de banda.
- Formato específico del cliente: la aplicación de escritorio busca varias páginas a la vez para una vista rica; la aplicación móvil busca una página para mantenerse ligera. Cada BFF sirve al patrón de su cliente.
El BFF es un tipo de agregador de API con personalidad: compone llamadas a servicios descendentes, pero siempre al servicio de un frontend específico en lugar de como una capa neutral y compartida.
Dónde se Superponen el BFF y la Pasarela de API
La confusión es comprensible porque los dos patrones comparten comportamientos superficiales. Ambos interceptan solicitudes de clientes. Ambos pueden enrutar a backends. Ambos pueden llamar a múltiples servicios y combinar resultados. Un diagrama de cualquiera de ellos parece una caja entre clientes y servicios.
La superposición es real pero superficial. La diferencia radica en la intención y la propiedad:
- Una pasarela de API agrega y enruta genéricamente, para todos los clientes, para centralizar la política.
- Un BFF agrega y enruta específicamente, para un frontend, para optimizar la experiencia de ese cliente.
La propia guía de Microsoft es contundente sobre qué tareas pertenecen a cada lugar. Las características transversales como la monitorización, la autorización y la limitación de velocidad deben abstraerse del BFF y ser manejadas por separado mediante patrones de estilo pasarela. El BFF solo debe contener lógica específica del cliente. Si pones la autenticación y el estrangulamiento en un BFF, habrás reconstruido la mitad de una pasarela, mal, y tendrás que hacerlo de nuevo en cada BFF que escribas.
Así que el límite práctico es este: si una responsabilidad es la misma para cada cliente, pertenece a la pasarela. Si cambia por frontend, pertenece al BFF.
BFF y Pasarela de API Trabajando Juntos
En sistemas de microservicios reales, rara vez eliges uno. Ejecutas ambos, en capas. La pasarela se sitúa en el borde. Los BFFs se sitúan detrás de ella.
Un flujo de solicitud típico se ve así:
- El cliente móvil envía una solicitud con su token de autenticación.
- La pasarela de API valida el token, aplica límites de velocidad, registra la solicitud para observabilidad y luego la enruta al BFF móvil.
- El BFF móvil llama al servicio de productos, al servicio de inventario y al servicio de precios, agrega los resultados, recorta la carga útil a lo que la pantalla móvil necesita y devuelve una única respuesta.
- La pasarela envía la respuesta de vuelta al cliente.
La arquitectura de referencia de Microsoft para este patrón hace exactamente eso: una pasarela de gestión de API maneja la autorización, monitorización, almacenamiento en caché y enrutamiento, y luego reenvía a los servicios BFF específicos del cliente que se ejecutan como funciones sin servidor, los cuales llaman a los microservicios subyacentes.
Cada capa hace lo que mejor sabe hacer. La pasarela es propietaria de las políticas que deben ser uniformes. El BFF es propietario de la forma que debe ser específica. El equipo de frontend implementa cambios en su BFF sin tocar la configuración de la pasarela, y el equipo de plataforma ajusta un límite de velocidad sin volver a desplegar ningún BFF.
Esta relación de capas es similar a cómo una pasarela coexiste con otra infraestructura en lugar de reemplazarla. Una pasarela no es un equilibrador de carga (pasarela de API vs. equilibrador de carga) ni una malla de servicios (malla de servicios vs. pasarela de API); cada uno maneja una capa distinta de la ruta de solicitud, y un BFF es simplemente una capa distinta más. Es el mismo principio detrás de la conectividad dirigida por API: dar a cada capa una tarea clara y dejar que solo haga eso.
Tabla de Decisiones: BFF vs. Pasarela de API
| Pregunta | Pasarela de API | BFF |
|---|---|---|
| ¿Quién lo posee? | Equipo de plataforma / infraestructura | El equipo de frontend que lo consume |
| ¿A quién sirve? | A todos los clientes, uniformemente | Un frontend específico |
| Función principal | Preocupaciones transversales: autenticación, limitación de velocidad, enrutamiento, observabilidad | Agregación y modelado de datos específicos del cliente |
| ¿Cuántos ejecutas? | Generalmente uno (por borde) | Uno por experiencia de usuario distinta |
| Acoplamiento | Flexible, agnóstico del cliente | Estrecho, específico del cliente por diseño |
| Cadencia de cambio | Estable, gobernado por la plataforma | Rápida, sigue la hoja de ruta del frontend |
| Corresponde a él | Cualquier cosa idéntica para cada cliente | Cualquier cosa única para un cliente |
Léelo como una pregunta de enrutamiento para las responsabilidades. Lo mismo para todos va en la pasarela. Diferente por frontend va en el BFF. Cuando una responsabilidad es ambas cosas (quieres autenticación centralizada pero también modelado de carga útil por cliente), esa es tu señal para ejecutar ambas capas, no para elegir un lado.
Cuándo Usar Cuál
Usa una pasarela de API cuando tengas múltiples servicios y necesites un lugar único y consistente para aplicar autenticación, limitación de velocidad y enrutamiento. Casi todos los sistemas de microservicios se benefician de uno. Si tienes más de un puñado de servicios expuestos a clientes, querrás una pasarela antes que cualquier otra cosa.
Usa un BFF cuando diferentes clientes tienen necesidades significativamente distintas del mismo backend, y una API de propósito general compartida se ha convertido en un cuello de botella. Desencadenantes comunes, según la guía de Microsoft:
- Un backend compartido requiere un gran esfuerzo para mantenerlo porque sirve a frontends en competencia.
- Sigues personalizando un backend de propósito general para acomodar múltiples interfaces.
- Móvil y web tienen necesidades de datos y rendimiento genuinamente divergentes.
Omite el BFF cuando todas tus interfaces realizan las mismas o similares solicitudes, o cuando solo una interfaz se comunica con el backend. Un BFF añade un salto de red, más servicios a desplegar y, probablemente, cierta duplicación de código entre los BFFs. Si una única API compartida sirve bien a todos los clientes, un BFF es una sobrecarga que no necesitas. Microsoft señala que una capa GraphQL con resolutores por frontend también puede eliminar la necesidad de un BFF separado, ya que los clientes solicitan exactamente los campos que desean.
Usa ambos cuando ejecutas microservicios a escala: la pasarela para una política uniforme en el borde, los BFFs detrás de ella para el modelado específico del cliente. Este es el estado final común, no uno exótico.
Errores Comunes
Poner la autenticación y la limitación de velocidad en el BFF. Este es el error principal. Las preocupaciones transversales pertenecen a la pasarela. Duplicarlas entre BFFs y obtendrás una deriva: el BFF móvil aplica una política, el BFF web otra, y tu postura de seguridad ahora es inconsistente por accidente.
Permitir que el BFF se convierta en un segundo monolito. Un BFF está destinado a ser pequeño y enfocado en una única experiencia. Cuando los equipos acumulan lógica de negocio compartida en él, vuelve a convertirse en un backend de propósito general y habrás reintroducido el mismo cuello de botella que se suponía que el patrón debía eliminar.
Usar una pasarela como un BFF. Algunos equipos añaden reglas de transformación de solicitudes por cliente directamente en la configuración de la pasarela para evitar construir un BFF. Esto funciona a pequeña escala, pero la pasarela es de propiedad centralizada, así que ahora el equipo de frontend presenta tickets al equipo de plataforma por cada ajuste específico del cliente. Has acoplado los equipos equivocados.
Construir un BFF cuando solo existe un cliente. Si tienes una única aplicación web y ningún otro cliente en el horizonte, un BFF es prematuro. Despliega la API compartida. Añade el BFF cuando un segundo cliente, divergente, llegue realmente.
Olvidar el contrato. Cada BFF y cada ruta de pasarela expone una API. Cada una necesita un contrato definido, pruebas y documentación, igual que cualquier otra API. Ignora esto y tu capa BFF "delgada" se convierte en una caja negra indocumentada contra la cual nadie fuera del equipo propietario puede integrarse. Consulta qué es un contrato de API para entender por qué esto es importante.
Dónde Encaja Apidog
Ya sea que una solicitud fluya a través de una pasarela de API, un BFF o ambos, cada capa expone un contrato de API. Apidog es donde diseñas, pruebas, simulas y documentas esos contratos. No construye, aloja ni reemplaza una pasarela o un BFF; te proporciona un único espacio de trabajo para las superficies de API que exponen.
Concretamente:
- Diseño: modela la respuesta agregada del BFF o los puntos finales enrutados de la pasarela con un enfoque de esquema primero en el diseñador visual, luego genera OpenAPI para que tanto tus equipos de frontend como de backend puedan construir sobre ello.
- Simulación: crea una simulación inteligente del BFF para que el equipo móvil pueda desarrollar sus pantallas antes de que existan los servicios descendentes del BFF. Este es el flujo de trabajo API-first que hace posible el trabajo paralelo de frontend y backend.
- Pruebas: construye escenarios de prueba automatizados que accedan a los puntos finales expuestos por la pasarela exactamente como lo haría un cliente real, validando la autenticación, los códigos de estado y la forma de la carga útil agregada.
- Documentación: publica documentación interactiva para cada BFF y ruta de pasarela para que cada equipo consumidor conozca el contrato sin leer la implementación.
El patrón que elijas es una decisión de arquitectura. El contrato que cada capa expone es una constante. Apidog maneja la constante, para que tus BFFs y pasarelas se mantengan diseñados, probados, simulados y documentados, sin importar cómo los conectes.
Prueba Apidog gratis para diseñar y simular tus contratos de BFF y pasarela antes de escribir una línea de código de backend.
Preguntas Frecuentes
¿Es un BFF un tipo de pasarela de API? No. Se superponen en que ambos pueden enrutar y agregar, pero un BFF es propiedad de un equipo de frontend y está adaptado a una experiencia de cliente, mientras que una pasarela de API es de propiedad centralizada y sirve a todos los clientes de manera uniforme. Un BFF típicamente se sitúa detrás de una pasarela.
¿Puedo usar un BFF sin una pasarela de API? Sí, pero generalmente no deberías hacerlo a escala. Sin una pasarela, cada BFF tendría que reimplementar preocupaciones transversales como la autenticación y la limitación de velocidad, lo que lleva a inconsistencia. La pasarela centraliza esas funciones para que cada BFF solo maneje el modelado específico del cliente.
¿Cuántos BFFs debería tener? Sigue la regla de Sam Newman de "una experiencia, un BFF". Construye un BFF separado para cada frontend significativamente diferente. Clientes similares mantenidos por el mismo equipo, como aplicaciones iOS y Android, pueden compartir un BFF.
¿Un BFF reemplaza mi pasarela de API? No. Son capas complementarias. La pasarela aplica una política uniforme en el borde; el BFF modela los datos para un cliente específico detrás de ella. La mayoría de los sistemas de microservicios reales ejecutan ambos.
¿Cuándo no debería construir un BFF? Omítelo cuando todos los clientes realizan solicitudes similares, cuando solo existe un cliente, o cuando una capa GraphQL con resolutores por frontend ya permite a los clientes obtener exactamente los datos que necesitan.
¿Dónde pertenecen la autenticación y la limitación de velocidad, en el BFF o en la pasarela? En la pasarela. Estas son preocupaciones transversales que deben ser uniformes para todos los clientes. Ponerlas en el BFF duplica la lógica en cada BFF e invita a la desviación de políticas.