Decisiones Tecnológicas

Decisiones de Plataforma y Stack Tecnológico

El stack técnico del Backend For Frontend (BFF) combina capacidades de integración empresarial (Enterprise Integration Patterns) con propiedades cloud-native. Esta base resuelve las necesidades de mediación SSO, proxy de tokens en tiempo real e integración con Salesforce.

Framework Principal: Quarkus 3.x (Java 21)

En lugar de depender de monolitos heredados basados en Spring Boot, el BFF se construirá sobre Quarkus.

¿Por qué Quarkus?

Arranque Casi Instantáneo (Native Mode): La compilación nativa mediante GraalVM permite que la API encienda en menos de 50ms, erradicando las penalizaciones de “Cold Start”. Cualidad crítica en arquitecturas Serverless o de auto-escalado en Kubernetes.
Micro-Huella de Memoria: Las imágenes nativas consumen muchísimo menos (típicamente <100MB), reduciendo drásticamente el coste operativo (OpEx) frente a máquinas virtuales Java estándar.
Productividad (Developer Joy): Ofrece Live Reload nativo, reduciendo la fricción y acortando los ciclos de desarrollo.
Ecosistema Compatible: Quarkus ofrece extensiones optimizadas de todos los estándares líderes (JAX-RS, Hibernate, Jackson, etc.).

Patrones de Integración: Apache Camel (Rol Secundario)

Mientras que la arquitectura marco original utiliza intensivamente Apache Camel para mensajería asíncrona pesada, en el caso del Brand Portal BFF, se optará por un rol deliberadamente minimizado. El BFF actúa como un API Proxy ligero y de altísimo rendimiento (gestionando pasarela de cookies y tokens) más que como un bus ESB orquestador pesado.

Tráfico Primario: Se despacha eficientemente mediante Filtros estándar JAX-RS y clientes REST declarativos nativos de Quarkus, sin capas de enrutamiento innecesarias.
Rol de Camel: Se retiene estrictamente como utilidad de fondo. Está disponible internamente por si el BFF requiere ejecutar alguna agregación (e.g., llamar a tres endpoints distintos para consolidarlos en una única respuesta JSON), pero no es la pieza protagonista de la pasarela estándar.

Transporte e Interfaz: Jakarta REST (JAX-RS)

El punto de entrada web emplea especificaciones estándar JAX-RS (ej. @Path("/bff/auth"), @POST).

Stateless Handling: Mantiene la lógica HTTP puramente centrada en aceptar la petición limpiamente.
Delegación: Un controlador JAX-RS recepciona el requerimiento y, si es necesario, lo inserta de forma asíncrona en una ruta Camel mediante puntos de interjección direct: o seda:.

Gestión de Estado (Sesión): Abstracción Unificada

Para conservar un diseño Cloud-Agnostic, pero altamente optimizado en Google Cloud:

El Repositorio de Sesiones (Almacén del Token) se define mediante interfaces abstractas puras de Java.
Para Google Cloud: Se inyecta la implementación para Firestore aprovechando las extensiones puras google-cloud-firestore.
Para Entornos On-Premise / Internos: Se provee una implementación de reemplazo regida por Componentes SPI tradicionales enfocándose en Bases de Datos Relacionales (PostgreSQL o MySQL) genéricas. Al no requerirse un throughput crítico en el acceso de las sesiones, incrustar topologías de caché en memoria como Redis sobre-ingeniaría la arquitectura. Emplear esquemas relacionales comunes junto con un Job programado de purga de caducidades es extremadamente eficaz y suficiente.