API gateway vs BFF: aprende cómo cada patrón afecta al versionado, rendimiento y separación entre endpoints públicos e internos para apps web y móviles.
Un punto de partida común es simple: un backend expone un conjunto de endpoints y tanto la app web como la móvil los consumen. Parece eficiente porque hay un único lugar para añadir funciones, corregir errores y aplicar reglas.
Luego llega la realidad. La interfaz web suele necesitar pantallas densas, filtros, exportaciones y acciones de administración. Móvil normalmente necesita menos campos, pantallas más rápidas, flujos tolerantes a trabajo sin conexión y cuidado con la batería y el consumo de datos. Incluso cuando la funcionalidad es "la misma", la mejor forma de la API para cada cliente rara vez coincide.
Con el tiempo, los endpoints derivan. Un equipo web añade campos extra para una nueva vista en tabla. Móvil pide quitar payloads pesados y combinar varias llamadas en una. Alguien añade un parámetro "solo para iOS". Otra persona reutiliza un endpoint interno de administración en la app pública porque "ya estaba allí". Lo que empezó como una API limpia se convierte en una colección de compromisos.
Los riesgos aparecen rápido:
Esta es la tensión central tras la discusión API gateway vs BFF. Quieres APIs públicas estables en las que móvil y web puedan confiar, mientras das a cada cliente espacio para evolucionar a su propio ritmo.
Un API gateway es la puerta de entrada para tus APIs. Los clientes llaman al gateway y este enruta las peticiones al servicio backend correcto. A menudo maneja preocupaciones compartidas que no quieres repetir en todas partes, como comprobaciones de autenticación, límites de tasa, registro de peticiones y moldeado básico de peticiones.
Un backend-for-frontend (BFF) es un backend pequeño construido para un cliente o grupo de clientes específico, como "web" y "móvil". El cliente llama a su BFF y el BFF llama a los servicios subyacentes. La idea clave es el foco: el BFF puede hablar el lenguaje del cliente (pantallas, flujos y payloads), aunque los servicios centrales sigan siendo más genéricos.
Lo que estos patrones no son: no reemplazan buenos servicios de dominio ni un modelo de datos limpio. Tus servicios centrales, bases de datos y reglas de negocio deben seguir siendo la fuente de la verdad. Un gateway o un BFF no deberían convertirse en un gran bulto de lógica de negocio que poco a poco se transforma en tu backend real.
Una forma simple de distinguirlos:
También se pueden combinar. Una configuración común es un gateway como borde público y, detrás, BFFs separados para web y móvil. El gateway maneja seguridad y reglas de tráfico exteriores, mientras cada BFF da forma a endpoints y respuestas para su cliente.
La mayor diferencia entre un API gateway y un BFF es dónde pones la lógica de "puerta": enrutamiento, comprobaciones de autenticación y moldeado de respuestas.
Con un API gateway, el cliente suele hablar con un único punto de entrada compartido. El gateway reenvía peticiones a servicios internos, realizando tareas básicas como validación de tokens, límites de tasa y enrutamiento por ruta.
Con un BFF, cada tipo de cliente (web, iOS, Android) llama a un backend construido específicamente para él. Ese BFF llama a servicios internos y devuelve una respuesta adaptada a las pantallas y las restricciones del cliente.
Una forma simple de imaginar la ruta de la petición:
La propiedad suele desplazarse también. Un equipo de plataforma o infraestructura típicamente posee el gateway porque afecta a todos los equipos y servicios. Un equipo de producto suele poseer un BFF porque se mueve con la UI y su ciclo de lanzamiento.
La autenticación normalmente fluye así: el cliente envía un token, la capa de borde (gateway o BFF) lo valida o lo pasa a un servicio de auth, y luego reenvía detalles de identidad (user id, roles) a servicios downstream. La diferencia es dónde aplicas reglas por cliente. Con un gateway, las políticas suelen ser genéricas y consistentes entre clientes. Con un BFF, puedes añadir moldeado específico por cliente, como devolver un payload más pequeño para móvil o combinar varias llamadas en una sola respuesta en redes lentas.
Ese paso de moldeado es donde los BFF sobresalen, pero también significa más piezas en movimiento para desplegar y mantener coherentes.
Un endpoint público es cualquier ruta de API a la que puedan llegar tu app web, tu app móvil, partners o terceros. Trátalo como hostil por defecto, porque no controlas la red por la que viaja ni el código cliente que lo llama.
Un endpoint interno está pensado para tráfico servicio-a-servicio dentro de tu sistema. Puede cambiar más rápido, asumir más contexto y exponer datos más ricos, pero nunca debería ser alcanzable directamente desde Internet.
Con un API gateway, la separación suele ser física y fácil de razonar: solo el gateway está expuesto y decide qué rutas externas existen. Todo lo que hay detrás se mantiene privado. Puedes permitir que las APIs internas sean expresivas, mientras el gateway aplica una superficie más reducida y segura.
Con el patrón backend-for-frontend, la separación es más sobre límites de producto. Cada cliente (web, iOS, Android) habla solo con su BFF, y el BFF habla con servicios internos. Eso te permite ocultar la complejidad interna: el BFF puede llamar a tres servicios, fusionar resultados y exponer una respuesta simple que coincida con lo que el cliente necesita.
La separación solo es segura si añades controles prácticos:
Ejemplo: una app móvil necesita una pantalla "Mis pedidos". El BFF puede exponer /orders con solo el estado del pedido y totales, mientras que el servicio interno de pedidos mantiene detalles de desglose de costes y flags de fraude privados.
El dolor del versionado suele aparecer cuando web y móvil se mueven a ritmos distintos. Un equipo web puede publicar y revertir en horas. Una app móvil puede tardar días o semanas por revisión de stores y usuarios que no actualizan. Esa brecha es donde la decisión API gateway vs BFF se vuelve práctica.
Con un API gateway puedes poner el versionado en una puerta de entrada (por ejemplo, /v1/..., /v2/...). Esto es fácil de explicar y de enrutar. La desventaja es que el gateway puede convertirse en un museo de versiones si muchos clientes y partners se quedan en variantes antiguas. Terminas soportando viejas formas del mismo dato por más tiempo.
Con un BFF, el versionado suele ser "por cliente". El BFF móvil puede permanecer en un contrato más antiguo mientras el BFF web avanza más rápido, incluso si ambos hablan con los mismos servicios internos. Eso reduce la presión de mantener versiones públicas eternamente. La contrapartida es más piezas en movimiento: ahora tienes múltiples decisiones de versión que gestionar y desplegar.
Versionar dentro de los servicios también funciona, pero empuja los cambios impulsados por clientes hacia lo más profundo del sistema. También puede hacer que el código interno sea más difícil de leer porque la lógica del servicio empieza a ramificarse según versiones clientes.
Los cambios no rompientes son tu mejor amigo: añadir campos opcionales, nuevos endpoints o aceptar campos de entrada adicionales. Los cambios rompientes incluyen renombrar un campo, cambiar un tipo (string a número) o eliminar un endpoint.
La desactivación funciona mejor cuando está planificada:
El rendimiento en una configuración API gateway vs BFF es principalmente un intercambio: un salto adicional dentro de tu sistema frente a menos saltos en la red desde el cliente. La opción más rápida suele ser la que reduce el tiempo de red lento e inseguro del cliente, aun si añade un pequeño paso extra en el servidor.
Un BFF suele ganar cuando el cliente de otro modo haría muchas llamadas. En lugar de que web y móvil llamen cinco endpoints y ensamblen resultados en el dispositivo, el BFF puede obtener lo necesario en el servidor y devolver una sola respuesta. Eso suele reducir la latencia total en móvil porque las redes celulares añaden demora a cada petición.
Mejoras comunes de rendimiento con gateway o BFF:
Pero el patrón también puede perjudicar. Cada capa añadida implica trabajo CPU y más sitios donde esperar. Si duplicas la misma lógica de agregación para web y móvil, puedes duplicar el trabajo y crear comportamiento inconsistente. El over-fetching es otra pérdida habitual: un endpoint genérico que intenta satisfacer todas las pantallas puede devolver payloads grandes que desperdician tiempo y ancho de banda.
Las realidades móviles hacen estos intercambios más agudos. Las redes inestables provocan reintentos y timeouts, y cada llamada extra consume batería. Los cold starts importan: si la app necesita varias peticiones antes de que la primera pantalla esté usable, los usuarios lo notan.
Una regla práctica: optimiza primero para menos llamadas del cliente y luego optimiza el salto añadido.
Si una pantalla necesita más de 2–3 llamadas secuenciales, considera la agregación. Si las respuestas son grandes y en su mayoría no se usan, considera dividir endpoints o usar un BFF adaptado por cliente.
Con API gateway vs BFF, la gran pregunta operativa es cuántas piezas móviles estás dispuesto a ejecutar y soportar. Un gateway suele convertirse en infraestructura compartida para muchos equipos y clientes. Los BFFs suelen ser servicios más pequeños, pero puedes acabar con uno por cliente (web, iOS, Android, partner), lo que aumenta la carga de despliegues y on-call.
En pruebas y releases, un gateway puede ser más seguro cuando lo que necesitas es enrutamiento, auth y límites. Los cambios están centralizados, así que un error puede afectar a todos. Los BFFs reducen el radio de impacto porque un cambio solo web se despliega en el BFF web, no en el móvil. La contrapartida es más pipelines que mantener y más versiones en vuelo.
Para la observabilidad, necesitas poder ver una petición de usuario única a través de capas, especialmente cuando una llamada móvil desencadena varias llamadas backend.
El escalado también cambia. Un gateway es un punto de estrangulamiento compartido: debe soportar picos y endpoints calientes sin convertirse en cuello de botella. Los BFFs te permiten escalar por cliente, lo que ayuda cuando el tráfico web salta en horario laboral y el móvil se mantiene estable.
En incidentes, las fallas pueden "moverse" según el patrón. Con un gateway, los problemas suelen mostrarse como 5xx generalizados o fallos de auth. Con BFFs, los problemas pueden aislarse a la funcionalidad de un cliente. Ten runbooks claros sobre dónde mirar primero y mantén comportamientos de fallback simples (por ejemplo, devolver una respuesta reducida en lugar de agotar el tiempo).
Elegir entre un API gateway y un BFF es menos teoría y más qué necesitan tus clientes en el día a día.
Empieza por tus clientes, no por tus servidores. Anota cada cliente que soportas (app web, iOS, Android, API para partners, admin interno) y lista lo que necesita cada pantalla clave. Si la misma vista de "Detalles del cliente" necesita campos y patrones de llamada diferentes en cada cliente, eso es una señal fuerte de conformado específico por cliente.
Mapea lo que tienes hoy. Toma tus endpoints actuales y marca qué está compartido (operaciones de dominio como pedidos, pagos, usuarios) frente a lo que está moldeado para presentación (un resumen de dashboard, un payload combinado de "home"). Las piezas compartidas pertenecen al backend central. Las piezas moldeadas para presentación encajan mejor en un BFF.
Decide dónde debe vivir el moldeado y las reglas. Si necesitas principalmente enrutamiento, auth, límites, caché y exposición segura de endpoints públicos vs internos, el gateway es el hogar natural. Si necesitas composición real (llamar a múltiples servicios, convertir seis llamadas en una, payloads distintos por app), pon esa lógica en código BFF para que siga siendo testeable y legible.
Elige una regla de versionado y desactivación que realmente vayas a cumplir. Por ejemplo: "No hay cambios rompientes sin una nueva versión, y cada campo obsoleto se mantiene 90 días." Con solo gateway puedes acabar versionando la superficie pública y traduciendo detrás. Con BFFs, a menudo puedes mantener las APIs centrales estables y versionar solo los endpoints del BFF por cliente.
Planifica el despliegue y mide. Antes de cambiar nada, captura métricas base: p95 de latencia, número de llamadas por pantalla, tamaños de payload y tasas de error. Despliega a un pequeño porcentaje primero, compara antes y después, y luego expande.
Un ejemplo simple: si tu app móvil se publica mensualmente pero tu portal web lo hace diariamente, un pequeño BFF móvil puede proteger la app de cambios frecuentes en el backend mientras la web sigue avanzando rápido.
Imagina una compañía con un portal cliente en web y una app de campo en móvil. Ambos necesitan los mismos datos centrales: clientes, trabajos, facturas y mensajes. El portal cambia semanalmente. La app móvil actualiza más despacio porque debe pasar revisión de tiendas y además necesita funcionar con señal débil.
El dolor aparece rápido. Los usuarios móviles quieren respuestas compactas, menos llamadas y flujos que soporten trabajo offline (por ejemplo, descargar los trabajos del día una vez y luego sincronizar cambios). El portal web está bien haciendo más llamadas y cargando pantallas más ricas porque siempre está en línea y es más fácil de actualizar.
La elección gateway-first mantiene tus servicios backend mayormente sin cambios. El gateway maneja autenticación, enrutamiento y pequeños ajustes como headers, límites de tasa y mapeo básico de campos.
El versionado queda en gran medida a nivel de API pública. Eso puede ser bueno: menos piezas móviles. Pero también significa que los cambios específicos para móvil suelen empujarte hacia versiones amplias como /v2 porque los endpoints subyacentes son compartidos.
La exposición de endpoints es más clara si tratas al gateway como la única puerta pública. Los endpoints internos permanecen detrás, pero debes ser estricto sobre qué puede alcanzar el gateway y qué publica.
Con un BFF móvil, la app móvil llama a endpoints diseñados para pantallas móviles y flujos de sincronización. El BFF puede agregar datos (detalles del trabajo + cliente + último mensaje), recortar campos y devolver un payload único que coincida con lo que la app necesita.
Qué cambia:
La trampa más grande en el debate API gateway vs BFF es convertir el gateway en un mini backend. Los gateways son excelentes en enrutamiento, auth, límites y moldeado simple. Cuando los llenas de reglas de negocio, obtienes lógica escondida difícil de probar, de depurar y fácil de romper con un cambio de configuración.
Los BFFs pueden fallar en la dirección opuesta: los equipos crean un BFF por pantalla o por feature y el mantenimiento se dispara. Un BFF debería normalmente mapear a un tipo de cliente (web, iOS, Android) o a un área de producto clara, no a cada vista UI. Si no, acabas duplicando reglas en diez lugares y el versionado se vuelve un trabajo de tiempo completo.
Los errores de versionado suelen venir de los extremos. Si versionas todo el primer día, congelas tu API demasiado pronto y mantienes variantes antiguas para siempre. Si nunca versionas, acabarás publicando cambios rompientes sin intención. Una regla simple funciona bien en la práctica: no versionar para cambios aditivos pequeños, pero versionar cuando eliminas algo o cambias su significado.
Publicar endpoints internos es donde los equipos se hacen daño. Exponer servicios internos directamente a Internet (aunque sea "temporalmente") convierte cada cambio interno en una potencial caída o incidente de seguridad. Mantén un límite claro: solo el gateway o el BFF deben ser públicos y los servicios internos deben seguir privados.
Los problemas de rendimiento suelen ser autoinfligidos: payloads sobredimensionados, demasiadas llamadas y sin presupuesto para la latencia. Por ejemplo, una app móvil puede necesitar solo el estado y totales de un pedido, pero recibe el objeto pedido completo con cada línea y campos de auditoría, haciendo cada petición lenta sobre celular.
Señales de advertencia a vigilar:
Si estás atascado en la decisión API gateway vs BFF, céntrate en qué se romperá primero en la práctica: releases, payloads y límites de seguridad.
Si respondes "no" a varias de estas preguntas, tu configuración actual probablemente te va a causar problemas conforme crezcan tus clientes:
Convierte las respuestas en un plan. El objetivo no es arquitectura perfecta, sino menos sorpresas al publicar.
Escribe tu contrato de API en lenguaje claro (entradas, salidas, códigos de error, qué está permitido cambiar). Elige un modelo de ownership: quién se ocupa de necesidades de cliente (web/móvil) y quién de los servicios de dominio. Decide dónde vive el versionado (por cliente o centralmente) y fija una regla de desactivación que seguirás.
Añade monitorización básica antes de grandes refactors: tasa de peticiones, p95 de latencia, tasa de error y los endpoints con mayor tamaño de payload. Prototipa los flujos de cliente más riesgosos primero.
Si construyes con AppMaster (appmaster.io), una aproximación práctica es mantener la lógica de negocio y los modelos de datos en el backend generado, y añadir una capa delgada de gateway o BFF solo cuando un cliente realmente necesite un moldeado distinto del payload o aislamiento de lanzamiento.
Si la lista rápida te resulta difícil de contestar, tómalo como señal para simplificar el contrato y endurecer la separación público vs interno antes de añadir más endpoints.
When should I use an API gateway instead of a BFF?Comienza con un API gateway cuando lo que necesitas principalmente es un punto de entrada público con controles compartidos como autenticación, límites de tasa y enrutamiento. Añade un BFF cuando web y móvil necesiten payloads claramente diferentes, menos llamadas desde el cliente o ciclos de lanzamiento independientes.
What logic should live in the gateway vs in a BFF?Un gateway es ideal para preocupaciones transversales y control de tráfico en el perímetro (enrutamiento, aplicación de auth, límites). Un BFF debe encargarse de la composición orientada al cliente, como combinar llamadas a varios servicios y recortar campos. Aun así, evita poner reglas de negocio centrales en ambos lugares.
How does versioning differ between a gateway-only approach and a BFF approach?Un gateway te da una “puerta” versionada única, clara y fácil de explicar, pero puede dejarte manteniendo versiones antiguas mucho tiempo. Un BFF permite versionar por cliente (por ejemplo, mobile puede quedarse estable mientras web evoluciona), a costa de gestionar más servicios y contratos.
What’s the safest rule for avoiding breaking changes for mobile and web?Prefiere cambios no rupturistas por defecto: añadir campos opcionales o nuevos endpoints. Crea una nueva versión si vas a eliminar campos, renombrarlos, cambiar tipos o cambiar su significado, porque los usuarios móviles pueden tardar semanas en actualizar.
How do I safely separate public endpoints from internal endpoints?Mantén los servicios internos privados y expón solo el gateway o el BFF a Internet. Filtra las respuestas para que los clientes reciban únicamente lo que necesitan y aplica autorización por ruta para evitar que acciones administrativas internas sean accesibles sólo porque un usuario inició sesión.
Will adding a gateway or BFF make my app slower?Usa un BFF cuando el cliente tendría que hacer muchas llamadas secuenciales: una agregación del servidor suele ser más rápida que varias rondas en redes móviles. Un gateway añade también un salto adicional, así que mantenlo ligero y mide latencias y tamaños de payload para evitar penalizaciones ocultas.
Which pattern is easier to operate and troubleshoot?Un gateway es un punto de congestión compartido: una mala configuración o una caída puede afectar a todos. Los BFF reducen el radio de impacto al aislar cambios por cliente, pero incrementan despliegues, monitorización y superficie de on-call.
What monitoring should I add for a gateway/BFF setup?Usa un ID de correlación y pásalo por gateway, BFF y todos los servicios downstream para poder trazar una acción de usuario de extremo a extremo. Mide un conjunto reducido de métricas por endpoint: tasa de errores, p95 de latencia, throughput y tamaño de payload.
What are the most common mistakes with API gateways and BFFs?Un error habitual es dejar que el gateway acumule reglas de negocio, lo que hace el comportamiento difícil de probar y frágil frente a cambios de configuración. Otro es multiplicar BFFs por cada vista: eso duplica la lógica y complica el versionado y el mantenimiento.
How can I apply this if I’m building with AppMaster?Mantén la lógica de negocio y los modelos de datos en el backend generado, y añade una capa fina de gateway o BFF solo cuando un cliente necesite realmente dar forma al payload o aislamiento de lanzamiento. En AppMaster (appmaster.io) esto suele implicar endpoints de dominio estables en el backend en Go y una capa pequeña para agregación o recorte específico para móvil.
27 ene 2026
8 min
26 ene 20268 min
21 ene 20268 minExperimente con AppMaster con plan gratuito.
Cuando esté listo, puede elegir la suscripción adecuada.
