En el desarrollo de software, el cambio hacia microservicios, arquitecturas nativas en la nube y la creciente variedad de dispositivos clientes (aplicaciones móviles, aplicaciones web, IoT, etc.) ha requerido nuevos paradigmas arquitectónicos. Uno de los patrones que más hemos usado sin nombre es el que se conoce ahora como la arquitectura Backend for Frontend (BFF). A medida que las aplicaciones se vuelven más distribuidas, la necesidad de adaptar los servicios backend a las necesidades individuales de los clientes se vuelve crítica para ofrecer experiencias de usuario rápidas, mantenibles y seguras.
¿Qué es la Arquitectura Backend for Frontend (BFF)?
Backend for Frontend es un patrón arquitectónico que proporciona una capa backend dedicada para cada interfaz frontend. Cada frontend (por ejemplo, aplicación móvil, aplicación web, dispositivo inteligente, etc.) puede tener diferentes necesidades de rendimiento, datos e interacción. En lugar de depender de una API monolítica o generalizada, un BFF adapta el backend a las necesidades específicas de un frontend dado.
En realidad, BFF no es ninguna novedad; es simplemente un nombre que se le ha dado a algo que hemos estado haciendo mucho en el mundo de los microservicios. Alguien le bautizó y el nombre se quedó. Para mí, no existe una diferencia real entre la arquitectura tradicional y BFF; quien piense lo contrario probablemente haya realizado microservicios solo para un tipo de cliente.
En resumen, para cada cliente o grupo de clientes (como móvil o web), se construye un backend separado que:
- Consolida u orquesta llamadas a varios servicios.
- Prepara datos en un formato amigable para el cliente.
- Maneja lógica específica vinculada al frontend.
Esto permite una separación de preocupaciones, facilitando la optimización de cada backend para el caso de uso específico del cliente.
¿Cómo Funciona BFF?
- Solicitudes del Cliente: El cliente (móvil, web, etc.) realiza una solicitud a su correspondiente BFF.
- Capa BFF: El BFF consolida datos de múltiples microservicios, realiza cualquier transformación u optimización y responde con una respuesta adaptada.
- Microservicios: El BFF interactúa con servicios subyacentes (por ejemplo, servicio de usuario, servicio de pedidos, etc.).
API Gateway en la Arquitectura BFF
En aplicaciones robustas, la capa de API Gateway es 100% necesaria y estaría entre el punto 1 y 2 anterior. Un API Gateway actúa como un punto de entrada único para todas las solicitudes de los clientes, proporcionando capacidades esenciales como enrutamiento de solicitudes, autenticación, autorización y limitación de la tasa de solicitudes. En la arquitectura BFF, el API Gateway puede trabajar en conjunto con múltiples BFFs para manejar las solicitudes de manera eficiente y segura.
¿Por qué Usar BFF?
- Experiencias de Usuario a Medida: Cada frontend — ya sea una aplicación móvil, de escritorio o un dispositivo portátil — obtiene exactamente los datos que necesita, sin desorden adicional.
- Reducción de la Complejidad: El BFF simplifica las cosas al personalizar cada backend, asegurando experiencias fluidas en todas las plataformas.
- Mejora del Rendimiento: Los BFF son aceleradores para tu aplicación. Al reducir las llamadas innecesarias a la API, aseguran respuestas más rápidas y usuarios más felices.
- Desarrollo Más Rápido: Cuando los equipos trabajan en diferentes BFFs para cada frontend, pueden moverse más rápido sin estorbarse unos a otros.
- Mayor Seguridad: En muchos sitios veréis que hacen referencia a que el BFF controla toda la interacción con el backend y que puede imponer medidas de seguridad estrictas, como validación de tokens, validación de entradas y limitación de la tasa de solicitudes, haciendo el sistema más seguro. Esto es completamente falso, esto ya lo teníais en las aplicaciones “tradicionales” y más aun si usáis un API Gateway.
¿Cuándo Usar BFF?
- Aplicaciones Multi-Plataforma: Para empresas que construyen aplicaciones multiplataforma (web, móvil, dispositivos inteligentes), BFF permite que cada plataforma obtenga una experiencia a medida.
Cuando arquitectos se confunden con BFF suelen añadir al ¿cuándo usar BFF?, las siguientes conclusiones:
- Orquestación de Microservicios: En una arquitectura de microservicios, los clientes pueden necesitar obtener datos de múltiples servicios (por ejemplo, servicio de usuario, servicio de pedidos, servicio de inventario). BFF puede actuar como el orquestador que reúne los datos necesarios de varios servicios y los presenta como una respuesta cohesiva al cliente. Esto es inherente a los microservicios.
- Optimización de APIs Legacy: Al migrar a microservicios o usar sistemas legados, un BFF puede ayudar a enmascarar las complejidades de la arquitectura subyacente. Proporciona una interfaz moderna al frontend mientras sigue interactuando con sistemas más antiguos. Claramente, viendo esta conclusión, veis que esto es obvio de microservicios y que incluso se confunde con el patrón Strangler Fig.
Esto No Es un Todo o Nada
Implementar BFF no es un enfoque de todo o nada. Muchas veces, comenzamos con una sola aplicación y luego añadimos la capa BFF solo para una aplicación específica, como una aplicación de movilidad. Esto permite una adopción gradual y manejable, ajustando la arquitectura a medida que las necesidades evolucionan.
Desafíos y Consideraciones
Aunque BFF trae muchos beneficios, introduce algunos desafíos:
- Mayor Sobrecarga de Mantenimiento: Tener “múltiples backends” para mantener (uno por frontend) puede aumentar la complejidad. Esto requiere medidas adicionales de monitoreo, escalado y seguridad.
- Problemas de Consistencia: Si no se diseña cuidadosamente, tener backends separados puede llevar a inconsistencias en los datos devueltos a diferentes clientes.
- Cuellos de Botella de Rendimiento: La capa BFF podría convertirse en un cuello de botella de rendimiento si no está optimizada para manejar numerosas solicitudes o si realiza cálculos pesados.
Mejores Prácticas de Implementación
Al implementar una arquitectura BFF, considera lo siguiente:
- Limitar la Lógica de Negocio en BFF: El BFF debería centrarse principalmente en orquestar y formatear datos para el frontend, no en implementar lógica de negocio compleja para eso tienes la siguiente capa de tu API de Microservicios.
Conclusión
La arquitectura Backend for Frontend no es un cambio de juego. Este nuevo nombre a algo que ya hemos estado haciendo.
Este nombre nos permite ser más claros para decir que estamos haciendo lo siguiente: entregar exactamente lo que necesita cada interfaz de usuario, ni más ni menos.